Penny Hírlevél

Jön ez a spam... Eleve nem iratkoztam fel rá, nem is vásárolok ott soha. Ezt még betudom annak, hogy nagyon általános az e-mail címem, könnyen megadhatta valaki más véletlenül. Viszont, az miért jó, hogy a leiratkozás linkre kattintva egy olyan oldal jön be, ahol meg kell adni az e-mail címet? Ilyen bonyolult lenne egy id-t hozzácsapni az URL-hez? Az extra pont már csak, hogy ha beírom a címet, azt nem találja a rendszer, erről ékes angol nyelven tájékoztat is, tehát leiratkozni lehetetlen.

( buga v | 2017. 05. 16., k – 13:12 )

Nézd meg a message header-ökben, hogy pontosan milyen címre küldték az eredeti levelet. Lehet kisbetű-nagybetű eltérés, alternatív domain, de más mail szolgáltató függő dolog is pl. gmail-nél a pont nem számít, azaz a foobar@, a foo.bar@, de akár a f.o.o.b.a.r@ kezdetű címzett esetén is azonos fiókba fog beesni.

( sj | 2017. 05. 16., k – 13:51 )

könnyen megadhatta valaki más véletlenül

hany eves vagy, kiralyfi?

Simán előfordul, hogy elgépelik, mindenféle kiegészítőket (számok a név mellett, kötőjelek, pontok) rosszul írnak, eltévesztik a domaint (gmail.hu vs gmail.com) és így kerül rossz címzetthez az email.

Főleg igaz akkor, ha a mail címed papíron adod meg, és utána kézzel rögzítik gépbe (mondjuk penny klubkártya igénylésekor), vagy úgy diktálod be valakinek.

Erre rásegít, ha népszerű neved van. És itt kapcsolódik a "hány oldal van belőle a telefonkönyvben" :)

Az egy dolog, hogy spammerek is ezt használják kifogásnak, ez még nem támasztja alá, hogy minden esetben erről van szó. Konkrét példákat hozunk neked, amikor ténylegesen véletlenről van szó, nem kifogásról. Oké, elhisszük, utálod a spamet és a spammereket. Mi is. De nem kell minden mögé az ördögöt látni.

nyilván a supershop generált kéretlenül egy kártyát, majd kéretlenül vásárolt az ismerősöm nevében, majd kéretlenül kiküldte az egyenlegértesítőt a kéretlen kártyáról amit az ismerősöm soha nem kapott kézhez, mégis gyűltek rajta a pontok

igazad van, ez nyilván sokkal valószínűbb forgatókönyv, minthogy az adatögzítő droid rosszul írta be a folyóírással leírt emailcímet

ne legyél már értetlen, b*szd meg, konkrét összegek voltak az emailben. azt is kéretlenül randomizálták?

Az agyad conflictol, kedves. Túlságosan is paranoid vagy, mindenütt spammereket látsz. Talán egy kicsit le kéne állnod a piler projektről, átadni másvalakinek, neked meg jót tenne helyette egy pihenés a Riviérán. Saját szervezésben, of course.
--
Blog | @hron84
Üzemeltető macik

( bucko | 2017. 05. 16., k – 14:07 )

Egy csomagküldő szolgáltatástól iratkoztam le. (Hogyan kerültem oda, azt takarja jótékony homály! :))

email 1: 

Az Ön kérelme az xxxxxxxxxx számmal van ellátva. A kérelme feldolgozását követően, egy visszaigazolást kap erre a címre.

Üdvözlettel
Ügyfélszolgálat

másnap email 2: 

Kérése teljesítve.

Bízunk benne, hogy elégedett volt az internetes szolgáltatásunkkal.

Üdvözlettel
Ügyfélszolgálat

Ez nem is egy spam, hanem fizetési kötelezettséggel járó szolgáltatás:
- Nem tudjuk mi volt a kérésem.
- Nem tudjuk megszűnt-e a regisztrációm.
- Nem tudjuk megszüntették-e az adatkezelést.
Jogilag. ;)

És pár óra múlva volt egy téves hívásom, tán ugyanonnan. Igaz, valami lányt kerestek.
Paranoia?

( uzsolt v | 2017. 05. 16., k – 15:30 )

Ilyen esetekben nem szoktam a leiratkozással vacakolni, egy szűrővel a spam-ek közé rakom, vagy olvasás nélküli törlésre ítélem. Nem tudom, mennyire igaz, amit néhány éve olvastam, miszerint sok esetben a levélben küldött leiratkozós linkre kattintással gyakorlatilag igazolod, hogy az adott email-t olvassák, és kapod továbbra is (sőt, akár egyre többet, vagy más címről). Bevallom, érzek benne realitást, ezért választom a belső megoldást.
Persze az esetedben (mivel az url-ben nincs egyedi azonosító) nyilván ez nem áll fenn.

" nem szoktam a leiratkozással vacakolni, egy szűrővel a spam-ek közé rakom"

Kár, sajnos sokan csinálják ezt, és szívatják a többieket, akik meg meg akarnák kapni a hírleveleket :) Pl a Gmail spam szűrője tanul a userektől, és egy idő után mindenkinél elkezdi spambe dobálni ezeket. Pedig a legtöbb helyen nem sokkal nehezebb leiratkozni, mint spambe tolni a levelet. Két kattintással több talán.

Azokról, amelyekről így "iratkozom" le, olyan helyekről jönnek, ahonnan nem kértem semmit, nem regisztráltam, stb. Néha előbukkan olyan ajánlat, amelyet arra hivatkozva küldenek, hogy még az iwiw-en (igen, iwiw) fogadtam el a megfelelő szabályzatot.
Persze a mondat másik felét lehagytad, miszerint kukába is mennek :)
De akinek meg ezek a levelek kellenek, megnézi szépen a Spam mappát (könyvtárat), és rányom arra, hogy "Nem spam". Én meg ismét rányomom, hogy "Spam". Aztán majd eldől, ki bírja tovább :D

"Néha előbukkan olyan ajánlat, amelyet arra hivatkozva küldenek, hogy még az iwiw-en (igen, iwiw) fogadtam el a megfelelő szabályzatot."

Annak tényleg a spamben a helye, és ilyen esetben tök oké, de az emberek egy jelentős része kábé mindenre rányomja mert hogy merészelik az ő idejét rabolni! Gondolok itt akár FB értesítésekre is, amik alapból be vannak kapcsolva, vagy paypal havi összesítőkre.

De ugye itt most egy penny hírlevélről van szó, amit úgy kapsz, ha igényelsz kártyát. Én pólós hírleveleket kapok rendelés után, nem sajnálom a spam gomb helyett az unsubscribe gombot nyomni. Főleg mert ugyanonnan várok fontos leveleket is (rendeléssel kapcsolatos infók).

"akinek meg ezek a levelek kellenek, megnézi szépen a Spam mappában"

Az a baj, hogy a spam amúgy is tele van minden szeméttel. Elég nehéz megtalálni köztük a véletlen odakerülő legit leveleket. Nem is szoktak az emberek ott turkálni, hacsak nem tudják, hogy fog érkezni valami, és jut eszükbe, hogy benézzenek. Egyszerűen nem életszerű csak azért napi 20-30 új spam között böngészgetni csak mert másnak nehezére esett leiratkozni a egy hírlevélről.

akkor vegyunk at par dolgot: *sokan* kell rosszul tanitsak a szurot, ha az masoknal is a spam mappaba kerul. Masreszt ez meg mindig csak a cimzettek toredeket erinti ilyen modon hatranyosan, hiszen nem mindenki 1 szolgaltatonal van.

Ha pedig valoban sokan inkabb bebsszak a spam folderbe, ahelyett, hogy leiratkoznanak, akkor elkepzelheto, hogy valami nem koser a kuldo oldalan. Eleve miert megy olyanoknak a level, akik nem orulnek neki? Lehet, hogy akarnanak leiratkozni, de nem megy/bonyolult/folosleges vegzalaskent elik meg a userek?

A cimzett oldali spamszures pedig ugy is megoldhato (felteve, hogy tanulo szurorol van szo), hogy ha gipsz jakab es tarsai a junk folderbe teszik ugyanazt a levelet, attol en meg az inbox-ban lassam.

"*sokan* kell rosszul tanitsak a szurot"
"nem mindenki 1 szolgaltatonal van"

"Gmail Now Has More Than 1B Monthly Active Users | TechCrunch"

"Ha pedig valoban sokan inkabb bebsszak a spam folderbe, ahelyett, hogy leiratkoznanak, akkor elkepzelheto, hogy valami nem koser a kuldo oldalan"

Vagy nem. Mint említettem sok user hajlamos egyből spam gombhoz nyúlni legit hírlevelek, értesítő emailek esetén is.

"A cimzett oldali spamszures pedig ugy is megoldhato (felteve, hogy tanulo szurorol van szo), hogy ha gipsz jakab es tarsai a junk folderbe teszik ugyanazt a levelet, attol en meg az inbox-ban lassam."

Meg, de megint oda lyukadtunk ki, hogy én tanítgatom a spam szűrőmet és dolgozok vele feleslegesen, csak azért mert mások félretanítják

nem vilagos, mit akartal megerositeni a gmail csillio userevel. Egy random lev/cimlistan biztos eszreveheto a szamuk, de mernek fogadni arra, hogy meg igy is csak egy toredek.

Vagy nem. Mint említettem sok user hajlamos

vagy de. Amint irtam, lehet, hogy ez van a hatterben. Lehet, hogy az elszabott leiratkozas. A 'sok user hajlamos' kijelentesed, gondolom, nem vonatkozik az osszes 1B gmail userre, akkor meg ertekelhetetlen kijelentes.

Meg, de megint oda lyukadtunk ki, hogy én tanítgatom a spam szűrőmet és dolgozok vele feleslegesen, csak azért mert mások félretanítják

ez egyeni szoc problema, batran jelezd a problemat a gmail ugyfelszolgalatan, hogy te nem akarod a felesleges felretanitasok miatt tanitani a szurodet. Egyaltalan mire alapozod, hogy a te leveleid azert lesznek spamnek jelolve, mert masok 'felretanitottak' azt? Valami hard evidence-re gondoltam a gmail spamszuro algoritmusa kapcsan...

Én meg úgy gondolom, hogy, ha nekem spam valami, az legyen _nálam_ beállítva, ha gúgli meg ez alapján úgy dönt, hogy nálad is kukába vágja ezt a küldőt, akkor talán a gúglinál kellene reklamálnod. Nem pedig annál, aki kifejezetten viszket xy.kft-től, ami történetesen neked pont a kedvenced. ;)

Én csak azt mondom hogy helyén kellene kezelni a dolgokat. A Google spam szűrője azért jó, mert tanul. Ennek a mellékhatása az, hogy ha hülyeségre van betanítva, akkor azt tanulja meg. Miért akarnád betanítani arra, hogy spam valami, ami nem az. Miért akarnál fogadni valamit, majd átirányítani a spam-be, amikor megtehetnéd, hogy eleve nem fogadod? Nekem ez elég visszásnak tűnik.

"xy.kft-től, ami történetesen neked pont a kedvenced"

Mire akarsz kilyukadni?

Miért akarnád betanítani arra, hogy spam valami, ami nem az.

hogy mi spam, az eleg masszivan szubjektiv megiteles ala esik. De nem a kuldo megitelese, hanem a cimzett megitelese ala. Az valoban igaz, hogy ha a user elkezdi felretanitani a szurot, az valoban problema, de egy jo spamszuro eseten max. maganak csinal problemat, masokra nincs hatassal a hulyesege. A te dolgod meg az (bar ez attol fugg, hogy melyik oldalon allsz: a masik user, a spammereDM kuldo vagy a spamszurot tekero ember), hogy ezt megoldd.

Az meg adottsag, hogy az end userek igen valtozatos okok miatt jelolnek spamnek egy levelet. De egy biztos: egyet sem azert, mert tenyleg akartak azt a levelet (a 10 spam kozott 1 jo levelet is megfog balesetet most hagyjuk). Ami a mailchimp* es mas spammerektol erkezo edm szarokra gondolva valahol ertheto is.

*: ne ebbe kapaszkodj, itt kicsit (de csak egy kicsit) sarkitottam

"Egyszerűen nem életszerű csak azért napi 20-30 új spam között böngészgetni csak mert másnak nehezére esett leiratkozni a egy hírlevélről." Attól nem beszélve, hogy ennyi erővel minek szenvedni kategorizálással egyáltalán. Jöhetne direktben az inboxba is, ha úgy is át kell nyálazni.

Elvileg a gmail támogat 1 kattintásos leiratkozást általa ismert szolgáltatásokhoz.

Egyébként meg a probléma a következő: Az emailben van egy leiratkozás link, ha erre rákattintasz, az egy GET request a szerver felé. Ez a request nem eredményezhet változást a szerveren. Nem megoldhatatlan, de ha valami gány, akkor ez az.

POST requestet kellene küldeni, azt meg emailből jó esetben formmal tudsz, de az sincs jól támogatva minden email kilensben. Tehát marad a link, marad a GET request, és marad az a plusz egy kattinás...

Ráadásul sok helyne van opció a leiratkozás mellé megadni indoklást, stb. Amíg nem kötelező, addig az egy elég hasznos cucc, mert jobb esetben értelmesen lehet a visszajelzések alapján fejleszteni a szolgáltatást, hogy másoknak később kevésbé legyen szívás a cucc.

az egy GET request a szerver felé.

eddig jo

Ez a request nem eredményezhet változást a szerveren.

pure bullshit. Az a GET keres nyilvan rendesen fel van parameterezve, hogy nyugodt szivvel megtortenhessen a modositas. En legalabbis nyugodtan tudtam utana aludni, semmi gond nem volt vele, mukodott szepen.

Tehát marad a link, marad a GET request, és marad az a plusz egy kattinás...

ez csak a sajat kotekedesed. Plz magyarazd el, hogy miert jobb a GET + POST, mint az 1 db GET. Probaljunk meg a "szerintem gany"-nal egy komolyabb lenni...

Ráadásul sok helyne van opció a leiratkozás mellé megadni indoklást, stb

lol, ez kb. olyan, mint a nemzeti konzultacios iv, biztos nem gyozitek feldolgozni a kommenteket. De, hogy segitsek neked, hogy megkapd a minden 1500 leiratkozobol 1 kitolto ember miert hagylak ott a picsaba titeket kerdesre adott ertekes velemenyet, probald igy: az 1. GET keres elvegzi a leiratkozast, amit vilagosan kozol is a generalt oldal, es amely oldalon ott van az opcionalis POST form. Mindenki boldog, es kevesbe irritalod a nepet...

"pure bullshit."

Félreértettél. Nem arról van szó, hogy egy GET hívás technikailag nem képes a szerveren változást eredményezni. Arról van szó, hogy a GET kérést nem illik/szabad/ajánlott arra használni, hogy változásokat idézzen elő a szerveren.

Javaslom olvasni a szabványt hozzá, lásd "Safe Methods": https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Idézem is: "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval."

"Plz magyarazd el, hogy miert jobb a GET + POST, mint az 1 db GET"

Nem mondom, hogy van ilyenre konkrét példa, de arra a linkre simán ráellenőrizhet a spam szűrő, esetleg a google miközben az emaileket crawl-olja, az email kliens is esetleg precache-elheti. Lehet most nem teszik (talán, nem tudom) de a szabvány megengedi, hiszen nem szabadna mellékhatással járnia, ezért ki tudja mikor változik meg.

Olvasmány a témához: http://thedailywtf.com/articles/WellIntentioned-Destruction

"lol, ez kb. olyan, mint a nemzeti konzultacios iv, biztos nem gyozitek feldolgozni a kommenteket"

lol, nem erről van szó. Mailchimp és hasonló szolgáltatók szoktak rákérdezni, hogy ha túl sok olyan visszajelzés érkezik, akkor a körmére néznek annak, aki a leveleket küldi. De igazad van, felesleges a visszajelzésekre hallgatni, miért is tegyük!!! Ó, és rögtön keverjük ide a politikát :)

Szerk: Annyit még a GET requestes témához, hogy... elmondhatod, hogy worksforme. Elmondhatod, hogy nincs rá példa, hogy most preload-elve lennének ezek. De miért is akarnál széllel szembe hugyozni, csak mert épp nem fúj elég erősen?

Igazából már:
https://tools.ietf.org/html/rfc7231#section-4.2.1 (a 2616 deprecated). Konkrétan annyi változott, hogy most már nem should not, hanem

When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action, it is
the resource owner's responsibility to ensure that the action is
consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within
query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search
index, etc.

Vagyis / rfc tilos, kedves sj :)

amint fentebb is irtam, magaval az elvvel nincs bajom. Azzal viszont igen, amikor egy kalapacsod van, es mindent szognek nezel, no matter what. Ez a fajta merevseg kb. olyan, mint amikor a rendor otthon anyatol is szemelyit, forgalmit, whatever ker, mert hat ... Erted...

Egyelőre azt értem, hogy hoztunk neked a "szerinted gány" helyett erősebb érvet, nevruetesen, hogy az a szabály. Ráadásul elég értelmesen meg is van magyarázva, hogy miért nem csinálunk változást publikusan elérhető gettel. Uh most neked kéne villantani valami "szerintednél" erősebbet, vagy revidálni a kissé nagyarcú pure bullshit megmondást.

Egyrészt erre, ha a te érvelési stílusodat hoznám, akkor mondhatnám, hogy "pure bullshit", így maradjunk annyiban, hogy ez max a te véleményed egyelőre. Másrészt ez még továbbra sem érv arra, hogy a GETre változtatni szabvány szerint tilos, még akkor is, ha ez a te dédelgetett usecasednek kevésbé tetszik. Persze ettől még lehetne a GETre változtatás pure bullshit, csak ehhez az érvnek kevés lesz.

"Nem mondom, hogy van ilyenre konkrét példa, de arra a linkre simán ráellenőrizhet a spam szűrő, esetleg a google miközben az emaileket crawl-olja, az email kliens is esetleg precache-elheti. Lehet most nem teszik (talán, nem tudom) de a szabvány megengedi, hiszen nem szabadna mellékhatással járnia, ezért ki tudja mikor változik meg."

User agent filter, IP filter stb. Ne csináljunk már úgy, mintha szakbarbárok lennénk.

Amúgy részben igazad van, részben nincs. Egy - a fejlesztők számára - ideális világban tényleg az lenne a legjobb, ha minden request azt csinálná, amire hitelesítve van: a POST posztolna, a PATCH frissítene a PUT feltöltene, a GET lekérne. Sajnos azonban baromira nem ideális világban élünk, a szoftvereknek pedig nem szép forráskóddal, hanem jó működéssel kell rendelkezniük, és ezt a "jó működést" alapvetően bizony-bizony a felhasználói igények adják meg.

Márpedig, ha a felhasználónak arra van igénye - és a legtöbbnek arra van -, hogy egy kattintással iratkozzon le, akkor te jöhetsz bármilyen fejlesztési paradigmával, metodológiával, azzal a felhasználót te meg nem győzöd. Avagy ez tényleg az "oldják meg, nem érdekel" kategóriája.

És igen, engem is baromira irritál a link utáni plusz egy kattintás. Nem akarom, nekem nincs rá szükségem, és bár értem a technikai korlátot e mögött, mint felhasználó, baromira leszarom. Ha X szolgáltató meg tudja oldani, hogy egy linkre kattintás után már nem kapok több levelet, és esetleg a leiratkoztatás UTÁN kérdezi meg, hogy miért, akkor a többi is meg tudná, és magasról szarom le, hogy az aktuális PM/vezfejl számára ez miért nem szép, vagy milyen standardot rúg fel.

Ha nagyon ragaszkodik a POST-hoz az adott szoftver fejlesztője, oldja meg külön AJAX-ból. Onnan lehet.
--
Blog | @hron84
Üzemeltető macik

"User agent filter, IP filter stb. Ne csináljunk már úgy, mintha szakbarbárok lennénk."

Tehát azt mondod, hogy menjek szembe a szabvánnyal, és tákolgassam meg ip filterrel, és ua szűréssel, mert az aztán nem szakbarbárkodás :)

Tényleg olyan nehéz az az egy plusz gomb megnyomása, amikor annyival meg van könnyítve a dolgod, hogy bejelentkezned nem kell? A vicc az, hogy szórakozunk már egy ideje hírlevélküldéssel, de ilyen visszajelzés nem jött még soha. Arra panaszkodnak sokan, hogy egyáltalán kapnak levelet, arra még senki, hogy egy helyett kétszer kell kattintani.

Az ajaxos megoldás oké, gondolhattam volna rá. Na látod, ez tisztább megoldás, mint az ip filteres szakbarbárkodásod :)

De amúgy végülis vicces, hogy a szabványt hülyézed le.

Attól, hogy valami szabvány, még nem biztos, hogy úgy jó, ahogyan lefektették. Ezt ez a thread remekül példázza is. Mindkét álláspont érthető és alátámasztott.

Most már csak azt kellene eldönteni, hogy a kedves hirdető végképp fel akarja-e bosszantani a potenciális ügyfelet, vagy csak simán belenyugszik, hogy a kiszemelt ügyfélnek pont most nem aktuális az aranyér végbélkúp.

Néhány dolog:

1) Akit bosszant az, hogy egy helyett kettőt kell kattintania, annál a probléma máshol van (ott, hogy megkapja). Ezt máshol kell kezelni (jobb tájékoztatás, kiemeltebb eleve fel nem iratkozás lehetősége.

2) Rossz oldalról van megközelítve a dolog. A probléma nem azzal van, hogy van egy ilyen szabály. Azzal van, hogy hogy nem igazán van rendes eszköz a feladat megoldására a szabály megkerülése nélkül.

Ami valójában nem is igaz. Tegnap nem gondoltam rá, de triviálisan, ajaxszal megoldható, hogy egy legyen az a kattintás, és mégis POST-ban menjen, aminek ott kell.

1) Akit bosszant az, hogy egy helyett kettőt kell kattintania, annál a probléma máshol van (ott, hogy megkapja).

ez csak a te velemenyed, amiben aligha all mogotted 1B user. A jobb tajekoztatas teljesen koser, csak epp teljesen fuggetlen attol a jogos igenytol, hogy ha xy le akar - akarmiert - iratkozni, akkor azt 1 kattintassal tehesse meg.

de triviálisan, ajaxszal megoldható, hogy egy legyen az a kattintás, és mégis POST-ban menjen, aminek ott kell.

mukodhet, de en meg ezt hivom ganynak :-)

Arról van szó, hogy a GET kérést nem illik/szabad/ajánlott arra használni, hogy változásokat idézzen elő a szerveren.

altalaban valoban nem is szoktak. De ezzel takarozni, hogy miert szivatod a feliratkozott usereidet, finoman szolva nem professzionalis. Egy leiratkozas pont az a kivetel, amikor nem kell mereven, sot fafejuen ragaszkodni az elmelethez. Foleg ugy, hogy a 'kar' worst case esetben is elhanyagolhato.

de arra a linkre simán ráellenőrizhet a spam szűrő

ha meg az unsubscribe linkre is ramegy, akkor az fucked by design (es ezt ugy mondom, hogy van a hatam mogott egy pici spamszuro tapasztalat).

esetleg a google miközben az emaileket crawl-olja

erre is kene valami hard evidence, hogy ez igy megy. De meg ha valoban igy, akkor is lehet a leiratkozo formot egy robots.txt-vel vedeni.

az email kliens is esetleg precache-elheti.

a jelenseget sem ertem, foleg hogy a web bug-ok ota a remote cimek(et) nem szokta keres nelkul megnyitni a mua. Ha neked ilyen van, surgosen nyiss egy ticket-et a gyartonal, mert ez biztonsagi problema, meg a spammerek orome is.

De igazad van, felesleges a visszajelzésekre hallgatni, miért is tegyük!!!

latom atment a mondandom, ezert leirom meg egyszer: 1500 leiratkozobol 1 tolti ki a miert hagysz el minket? kerdest.

De miért is akarnál széllel szembe hugyozni, csak mert épp nem fúj elég erősen?

igen, worksforme. De alapvetoen eltevedtel: az ugye megvan, hogy nem nekem van problemam, mert beragnak a userek az 1 kattintasos unsubscribe miatt, hanem neked van problemad egy haragra ingerlo megoldas miatt...

a szakmai erv mindossze annyi volt, hogy mereven eroltettek paran egy - amugy altalanosan ertelmes - szabvanyt. De arra egy szakmai ervet nem lattam meg (a google crawler bejarja es hasonlokat ne csufoljuk mar szakmainak), hogy miert rossz 1 db GET-tel implementalni a feature-t. Hogy worst case milyen kart okoz, stb.

De a valodi kerdes az, hogy egy rfc miatt tenyleg szivatni/irrtalni akarod a usereket?

jaja, "mindössze". ne haragudj, de fordítva ülsz a lovon. A szabványok azért vannak, hogy tartsák őket. A kis izéd nem önmagában van, hanem, tudod, interakcióban van a külvilággal. A külvilág meg arra számít, hogy szabványnak megfelelően működik. És a külvilág nem csak egy crawler, hanem pl egy vírusírtó, ami automatán belenéz neked a linkbe, egy böngésző kiterjesztés, ami prefetchel, vagy pl az üzemeltető, aki a lefejlesztett barkács taknyodat beteszi mondjuk egy loadbalancer mögé. Ami mondjuk bele keepaliveol, hiszen GET, esetleg elcacheli az eredményt, hogy kímélje a backendet. Vagy még úgy nagyjából ezer más dolog. Ha szerinted úgy kell szoftvert fejleszteni, hogy a primary positive pathon kívül mindent le lehet szarni, az igen szomorú.

És elérve a valódi kérdéshez: nem, én simán el tudom fogadni, hogy ez valid usecase (bár vegyük észre, hogy ennek alátámasztására egyelőre csak a véleményed van -- ami nem feltétlen baj egyébiránt, szoktak lenni így usecasek). Viszont az már csak a te korlátolt nézőpontod, hogy az egy klikket kizárólag HTTP GET formában lehet megoldani. Ugyanis ez a usert baromira nem érdekli, részletkérdés. Akár egy reply email is lehetne, vagy bármi. A te dolgod az, hogy ezt megold. Az ügyfeled meg valószínűleg elvárja, hogy ne taknyoljál neki, hanem a szabványokat betartó dolgot adj át (mert bizony az is egy usecase, pl mert üzemeltetné, lásd fent). Ja, hogy ahhoz lehet kicsit többet kéne dolgozni, ezért inkább, ha az ügyfeled elég hülye hogy benyelje, inkább leszarod az RFCt? Persze, ez költséghatékony, nincs ezzel gond, csak vedd észre, hogy vérpistike lettél, az álláspontod nem szakmailag védett.

A kis izéd nem önmagában van, hanem, tudod, interakcióban van a külvilággal.

eddig jo

Ha szerinted úgy kell szoftvert fejleszteni, hogy a primary positive pathon kívül mindent le lehet szarni, az igen szomorú.

az, de hagyd azt a szalmababot.

egy vírusírtó, ami automatán belenéz neked a linkbe

melyik tolti le az unsubscribe linket?

egy böngésző kiterjesztés, ami prefetchel

itt is ugyanaz a kerdes

pl az üzemeltető, aki a lefejlesztett barkács taknyodat beteszi mondjuk egy loadbalancer mögé. Ami mondjuk bele keepaliveol,

gondolom, a cache interval, expiry, meg ilyen feature-oket a ti loadbalancer-eitek is ismerik. De tegyuk fel, hogy nek. Es akkor mi van? Ha a user nem kattintott ra a linkre, akkor semmi. Ha rakattint, akkor ezzel le is iratkozott. Ha megis meghivja ugyanazt a linket, akkor baj tortenik? Akkor sem.

az már csak a te korlátolt nézőpontod, hogy az egy klikket kizárólag HTTP GET formában lehet megoldani.

en ezt valasztanam. Fentebb javasoltak egy workaround-ot, ami eleg ronda.

Az ügyfeled meg valószínűleg elvárja, hogy ne taknyoljál neki, hanem a szabványokat betartó dolgot adj át

az ugyfelek altalaban azt varjak el, hogy helyesen mukodjon az x dolog. Sot, adott esetben meg egy ertelmes limitation is beleferhet. De a fenti aggodalmaidat nem vettem keszpenznek, vannak kerdeseim. Mert egyelore nem latom, hol bukna meg az en megoldasom.

Ja, hogy ahhoz lehet kicsit többet kéne dolgozni, ezért inkább, ha az ügyfeled elég hülye hogy benyelje, inkább leszarod az RFCt? Persze, ez költséghatékony, nincs ezzel gond, csak vedd észre, hogy vérpistike lettél, az álláspontod nem szakmailag védett.

egy kisse mintha jobban belelolvaltad volna a magad az indokoltnal. Ami az RFC megkerdojelezhetetlenseget illeti, vannak ketsegeim, hogy te mindig, minden esetben betartod a szabalyokat (amik pedig ugye azert vannak, nem?). Ha pl. a gyalogatkelohelyen piros a lampa, akkor megvarod a zoldet, tiszta sor, en is. De ha epp sehol senki az egesz utcaban, akkor is? En akkor hajlamos vagyok atmenni a piroson. Miert? Mert senkinek nem faj. Ezert csinalom az unsubscribe-ot 1 kattintassal, es a szerveroldalon GET hivassal. Ha majd felmerul olyan korulmeny, ami ezt lehetetlenne teszi (mert valakinek fajna), akkor majd johet mondjuk az ajaxos ganyolas. De egyelore nem merult fel ilyen gubanc ebben a topikban...

"az, de hagyd azt a szalmababot."
maximum slippery slope, de te jöttél ezzel.

"melyik tolti le az unsubscribe linket?"
mit tudom én, amelyiknél éppen majd úgy gondolják.

"gondolom, a cache interval, expiry, meg ilyen feature-oket a ti loadbalancer-eitek is ismerik."
ja értem, más cucca az beszélje a szabványokat. :) És egyébként az azokhoz szükséges headereket helyesen csinálod, vagy ha valami use-case miatt annak is keresztbe kell verni, akkor azt is lehet?

"Ha a user nem kattintott ra a linkre, akkor semmi. Ha rakattint, akkor ezzel le is iratkozott. Ha megis meghivja ugyanazt a linket, akkor baj tortenik? Akkor sem."

Ha a user nem kattintott, ellenben valami más helyette meg igen, akkor leiratkozott egy olyan user, aki nem akart. Ha szerencséd van, akkor sok ilyen usered is lehet :)

"en ezt valasztanam. Fentebb javasoltak egy workaround-ot, ami eleg ronda."
Ja, az. Ez is elég ronda (ti kerszetbeszarja a protokollt), és még nem is szabványos.

"gy kisse mintha jobban belelolvaltad volna a magad az indokoltnal. Ami az RFC megkerdojelezhetetlenseget illeti, vannak ketsegeim, hogy te mindig, minden esetben betartod a szabalyokat (amik pedig ugye azert vannak, nem?). Ha pl. a gyalogatkelohelyen piros a lampa, akkor megvarod a zoldet, tiszta sor, en is. De ha epp sehol senki az egesz utcaban, akkor is? En akkor hajlamos vagyok atmenni a piroson. Miert? Mert senkinek nem faj."

Ennek a példának semmi relevanciája. Az ott egy tökéletesen lokális döntés. Az, hogy a szabvány be nem tartása miatt mikor puffan valami el, az nem.

"Ezert csinalom az unsubscribe-ot 1 kattintassal, es a szerveroldalon GET hivassal. Ha majd felmerul olyan korulmeny, ami ezt lehetetlenne teszi (mert valakinek fajna), akkor majd johet mondjuk az ajaxos ganyolas. De egyelore nem merult fel ilyen gubanc ebben a topikban..."
Megint csak fordítva ülsz a lovon. Azt várod, hogy mutasson valaki egy konkrét esetet, ahelyett, hogy felfognád, hogy potenciális bombát szállítasz. (Arról nem beszélve, hogy bárki mond valamit, hogy mit okozhat, egy vállrándítással elintézed, hogy szerinted az nem gond. Ez így elég kényelmes védekezés, csak semmi értelme, mert úgy döntöttél, hogy csakazértis neked van igazad, mert még nem volt ebből gondod.
És egyébként hajrá, csináld. Csak abból az arcból vegyél vissza egy kicsit, hogy "pure bullshit" hogy nem lehet ilyet csinálni. Egyelőre ott tartunk, hogy "szertintem bizonyos speciális usecaseeknél el lehet tőle térni". Látok némi különbséget.

mit tudom én, amelyiknél éppen majd úgy gondolják.

ennyi? Nincs is ilyen allat, de egyszer majd biztos lesz?

ja értem, más cucca az beszélje a szabványokat.

kisse osszecsusztatsz dolgokat: a http protokollt en is pont ugy beszelem, mint a fiktiv load balancer-ed. Meg mielott ram ragasztod, hogy leszarom a szabvanyokat, tisztazzuk: 1 konkret dolog eseten mast gondolok, mint az adott rfc, esezert is hoztam a piros lampas peldat.

Ha a user nem kattintott, ellenben valami más helyette meg igen,

meg mindig nem talaltunk ilyen allatot.

bárki mond valamit, hogy mit okozhat, egy vállrándítással elintézed

valaki kitakarta azokat a reszeket, ahol azt is leirom, szerintem miert nem valodi issue az adott felvetes?

Csak abból az arcból vegyél vissza egy kicsit, hogy "pure bullshit" hogy nem lehet ilyet csinálni. Egyelőre ott tartunk, hogy "szertintem bizonyos speciális usecaseeknél el lehet tőle térni". Látok némi különbséget.

azt a velemenyemet meg mindig tartom, hogy pure bullshit, hogy 1 kattintassal nem lehet megoldani a leiratkozast (normalisan), ezert teljesen foloslegesen irritalni kell a usereket. Mert egy listarol valo unsub pont az a spec. use case, ahol nem kell mereven ragaszkodni az allapot valtozast csak post-on keresztul szabad dogmahoz.

"ennyi? Nincs is ilyen allat, de egyszer majd biztos lesz?"

nem, csak nincs kedvem keresgélni. És igen, én simán el tudok képzelni olyan szoftvert, ami belenéz ilyen linkekbe automatán a user nevében. És nem fogja észrevenni, hogy az egy unsubscribe link. És ez szerintem designnál igen, ennyi.

"kisse osszecsusztatsz dolgokat: a http protokollt en is pont ugy beszelem, mint a fiktiv load balancer-ed."

Kivéve ugye a GETet ebben a konkrét esetben. Más esetben meg ugye ilyen logika mentén simán lehet valami más usernek kellemetlen dolog, ami miatt letojod. Vagy ez egyetlen rákfenéje az egész HTTPnek, egyébként tökéletes? (de jó lenne)

"Meg mielott ram ragasztod, hogy leszarom a szabvanyokat, tisztazzuk: 1 konkret dolog eseten mast gondolok, mint az adott rfc,"

"esezert is hoztam a piros lampas peldat."
ami továbbra is teljesen irreleváns, csak e fölött átsiklottál.

"valaki kitakarta azokat a reszeket, ahol azt is leirom, szerintem miert nem valodi issue az adott felvetes?"
Ja. Vagy legalábbis én azon túl, hogy "én ilyet még nem láttam" más erre vonatkozó részt nem láttam. (Lehet valaki GETtel letörölte :D) És ami ráadásul fals, mivel visszakövethetetlensége híján gyak esélytelen, hogy észrevedd, ha volt ilyen.

"azt a velemenyemet meg mindig tartom, hogy pure bullshit, hogy 1 kattintassal nem lehet megoldani a leiratkozast (normalisan), ezert teljesen foloslegesen irritalni kell a usereket. Mert egy listarol valo unsub pont az a spec. use case, ahol nem kell mereven ragaszkodni az allapot valtozast csak post-on keresztul szabad dogmahoz."
Most erre mit mondjak, szerintem meg nem, 1:1 :)