Nette JWT User Storage – alternativa k PHP session

@akadlec: Než začnu vymýšlet jak to udělat, ujistím se, že mluvíme o tom samém. Proč máš kvůli Doctrine upravenou implementaci Nette\Security\IUserStorage? Popis mi sedí spíše na App\Model\UserManager ze sandboxu.

@DavidMatějka @akadlec Jo takhle, rozumím :) serializer určitě plánuju doplnit.

@FilipKlimeš idealni :)

souki napsal(a):

Je to nesmysl. Úplně stejný nesmysl mají v Rails a i tam už zařazují zpátečku.

Můžu poprosit o nějaký odkaz?

Pokud bude mít cookie s daty po převodu do JSON a šifrování 500 bajtů (velmi optimistický odhad) a na webu bude 50 obrázků/css/js, tak to znamená 25 kB uploadu.
Na EDGE se 25kB bude uploadovat zhruba 2 sekundy (100kbps). A to ještě naivně předpokládám, že to jde všechno v jednom požadavku.

Gratuluji! Ušetřili jsme zhruba 2ms na serveru nepoužitím databáze/redis/fs a přidali jsme 2s na klienta.

Za a) tohle je extrémní případ, za b) do JWT nedoporučuji ukládat mnoho dat (např. celou entitu uživatele) a za c) nepoužití FS/DB/Redisu je jen jedna z výhod. Lepší mi přijde např. to, že není potřeba řešit škálování PHP sessions.

Editoval Filip Klimeš (21. 8. 2015 12:50)

Invalidace JWT se řeší blacklistem na serveru podle UID tokenu.

@souki me fascinuje, jak to a priori odsuzujes. Pritom usecase, ktery si uvedl, jen znaci, ze programator je debil. Domena se stacic obsahem ma byt bez cookie. Dale, vsichni dobre vime, ze na mobile neni problem tolik s objemem dat, ale s roundtripem a poctem spojeni. Neposledne, i phpseesid pridava datovou zatez.

A jeste jeden usecase, ikdyz ne mozna aktualne pomoci tohoto doplnku implementovatelny: (napr.) na signaly.cz mame na kazdy strance login form. No a protoze kazdy login form je obranen proti CSRF, tak s na kazde strance startuje session pro uzivatele. A to uz nejaky rozdil udela.

Jan Tvrdík napsal(a):

Invalidace JWT se řeší blacklistem na serveru podle UID tokenu.

Takže stejně musíš poslat dotaz do databáze (resp. redisu, memcache…). Navíc, pro ten jednoduchý příklad s počtem shlédnutí bys musel vkládat nový záznam při každém požadavku, takže budeš mít v databázi řádově víc záznamů než při normální session.

A to není to nejhorší, úplně se ti to rozpadne jakmile uživatel pošle dva požadavky zároveň.

Okay, pro případ počítání přístupů v session je JWT nevhodná (pokud nechám stranou otázku, zda je existencionálně nutné mít vždy správný počet návštěv v session). Měl bys nějaký netriviální případ, kdy by to mohl být vážný problém? Přijde mi, že do session ukládám data, která kromě autentifikace primárně mění pouze UX uživatele a tedy je jen uživatelovo věc, jestli mi podstrčí starou cookie s např. jiným počtem přístupů.

Jan Tvrdík napsal(a):

Když nad tím tak přemýšlím, tak je tam asi ještě horší problém. Úplně každý zápis do session může selhat, pokud na server dorazí dva požadavky zároveň. Protože ty na serveru nic neukládáš, tak pokud session neměníš, tak pošleš zpátky stejnou cookie, jakou jsi dostal od klienta, přestože v té době může už existovat novější.

Ano, to máš pravdu.

Jen aby bylo jasno, implementoval jsem zatím pouze IUserStorage, tedy JWT používám pouze pro autentifikaci uživatele. Ukládání session dat do JWT jsem zatím neřešil, SessionStorage a vlastně celá Session zůstaly původní.

Možná jsem mohl zvolit trochu méně provokativní a tím pádem zavádějící titulek vlákna, ale to by zase nepřitáhlo tolik pozornosti ;)

hrach napsal(a):

@souki me fascinuje, jak to a priori odsuzujes. Pritom usecase, ktery si uvedl, jen znaci, ze programator je debil. Domena se stacic obsahem ma byt bez cookie. Dale, vsichni dobre vime, ze na mobile neni problem tolik s objemem dat, ale s roundtripem a poctem spojeni. Neposledne, i phpseesid pridava datovou zatez.

Doména se static obsahem už je ale zase bottleneck s HTTP/2 (kde ale zase na druhou stranu bude komprese hlaviček).

Všichni píšete, že se tam nemá ukládat větší množství dat, ale třeba jenom id/hash uživatele. Jenže to přesně dělá už ta normální session :) V čem teda je přínos JWT? Stejně si pak musím na serveru k tomu ID někde najít dodatečné informace a přesně to dělám i se session.

Prostě mi přijde, že se vymyslelo řešení, zjistili se jeho limity, tak se vymyslelo omezení a tím se obloukem došlo k tomu původnímu řešení pomocí session.

Přijde mi daleko rozumnější používat už existující řešení a spíš případně řešit jeho implementaci. Například nepárovat sessionid s daty, dokud to není skutečně potřeba, neukládat v souborech, ale někde distribuovatelně a podobně.
Tohle řešení je vhodné jen pro krajní případy, ale vidím tam spoustu nových problémů a na druhé straně žádný, který by nebyl už 10× vyřešený lépe na straně serveru.

Editoval souki (21. 8. 2015 15:34)

Všichni píšete, že se tam nemá ukládat větší množství dat, ale třeba jenom id/hash uživatele. Jenže to přesně dělá už ta normální session :)

• normalni session ma ulozeny nahodny hash. Pomoci toho hashe php sahne na disk/redis/… a najde data uzivatele, kde je ulozeno jeho id. Posleze si teprve sahnu do db pro entitu uzivatele.
• jwt ma ulozeny id uzivatele a „digitalni podpis“ dat. Z cookie prectu id uzivatele, overim jeho podpis a sahnu si do db pro entitu uzivatele.

Rozdil je snad zrejmy. Ad delka a objem dat:

• normalni session: 26 znaku pro identifikator
• jwt: napr. 133 znaku pro tyto data {"loggedInAs":"admin","iat":1422779638} (vzano z odtu)

hrach napsal(a):

Všichni píšete, že se tam nemá ukládat větší množství dat, ale třeba jenom id/hash uživatele. Jenže to přesně dělá už ta normální session :)

• normalni session ma ulozeny nahodny hash. Pomoci toho hashe php sahne na disk/redis/… a najde data uzivatele, kde je ulozeno jeho id. Posleze si teprve sahnu do db pro entitu uzivatele.
• jwt ma ulozeny id uzivatele a „digitalni podpis“ dat. Z cookie prectu id uzivatele, overim jeho podpis a sahnu si do db pro entitu uzivatele.

Rozdil je snad zrejmy. Ad delka a objem dat:

• normalni session: 26 znaku pro identifikator
• jwt: napr. 133 znaku pro tyto data {"loggedInAs":"admin","iat":1422779638} (vzano z odtu)

Ale v čem si teda s JWT pomůžu? Mělo by to řešit škálovatelnost, ale stejně si pak musím sáhnout do databáze (nebo někam), abych k identifikátoru získal další data – tzn úplně stejně jako u session.

Stejně tak u session nemusí jít o náhodný hash, ale může to být třeba hash s kontrolní částí, aby šel ověřit bez databáze.

Filip Klimeš napsal(a):

souki napsal(a):

Ale v čem si teda s JWT pomůžu? Mělo by to řešit škálovatelnost, ale stejně si pak musím sáhnout do databáze (nebo někam), abych k identifikátoru získal další data – tzn úplně stejně jako u session.

Stejně tak u session nemusí jít o náhodný hash, ale může to být třeba hash s kontrolní částí, aby šel ověřit bez databáze.

Protože do session storage se při horizontálním škálování potřebuješ dostat ze všech instancí dané aplikace a to může být problém. Pokud používáš JWT a nepotřebuješ si do session ukládat nic navíc, nemusíš se tímto problémem zaobírat.

V obou případech ale samozřejmě musíš řešit přístup z instancí do DB, který se ale dá obejít snadněji.

Btw nebylo to nedávno, kdy Rohlíku zabily sessions server? ;)

Chápu, co to má v teorii řešit. V praxi to ale naráží na ty samé problémy jako session. Stejně se nakonec v cookie přenáší identifikátor, podle kterého se v nějakém zdroji hledají data. Není mi tedy jasné, co přesně JWT vyřešilo.

Řešil jsem tohle, když jsme migrovali do cloudu – tam je právě spousta instancí a potřebují sdílet session. Jednoduše se ale ukládají session data do Redisu (respektive Elasticache) a je po problému. Je to škálovatelné, replikované, … Vzniká tam prodleva ~1ms na komunikaci, ale to je pořád pohodička oproti alternativám.

Filip Klimeš napsal(a):
A pro jistotu ještě zdůrazním, že tato knihovna je pouze alternativa, ne návrh na kompletní odstranění PHP Sessions z Nette.

Mě na tom právě nejvíc děsilo, že by se to začalo slepě používat bez znalosti úskalí. Pokud je cílem vyřešit nestabilní úložiště session id a nic jiného, tak proč ne. Do quick start bych to ale určitě nedával :)

Ještě ale hloupý dotaz – jak se vyřeší odhlášení? Pokud to správně chápu, tak se pouze smaže cookie. Jak se zajistí, aby stejnou cookie už nemohl nikdo použít?

souki napsal(a):

Mě na tom právě nejvíc děsilo, že by se to začalo slepě používat bez znalosti úskalí. Pokud je cílem vyřešit nestabilní úložiště session id a nic jiného, tak proč ne. Do quick start bych to ale určitě nedával :)

Super, konečně si rozumíme :) Tohle není RFC, jen doplňek do Nette FW.

Ještě ale hloupý dotaz – jak se vyřeší odhlášení? Pokud to správně chápu, tak se pouze smaže cookie. Jak se zajistí, aby stejnou cookie už nemohl nikdo použít?

Naopak, dobrý dotaz. Nabízí se několik řešení. Krátká expirace tokenů a refreshování, aby se zachovalo UX. Nebo můžeš použít JWT blacklist, ten ale samozřejmě přináší nutnost nějakého úložiště.

V případě katastrofického scénáře lze na serveru vyměnit secret a tím zneplatnit všechny dosud vydané JWT tokeny.

@FilipKlimeš no hele upřímně, fakt mi to tak zní (a zjevně nejenom mně). Titulek jsem ti změnil, může být?

Jan Tvrdík napsal(a):

Když nad tím tak přemýšlím, tak je tam asi ještě horší problém. Úplně každý zápis do session může selhat, pokud na server dorazí dva požadavky zároveň. Protože ty na serveru nic neukládáš, tak pokud session neměníš, tak pošleš zpátky stejnou cookie, jakou jsi dostal od klienta, přestože v té době může už existovat novější.

Není tohle zcela zásadní problém? Ideálně totiž přeci chceme token měnit co nejčastěji.

edit: Teď mě napadá, že v JWT nemá vůbec žádný smysl token měnit, protože všechny předchozí budou stále platné, nebo ne?

Editoval Elijen (22. 8. 2015 19:07)

skrivy napsal(a):
Problem snad vsech session storage implementovanych primo v PHP jsou zamky – PHP se snazi drzet sessions konzistentni. V pripade soubehu nekolika requestu s jednim sessionid, kdy jeden z pozadavku trva treba 20 vterin,…

Pokud používáš session jen na uložení id uživatele, tak přeci žádný problém se zámky mít nebudeš:

session_start();
$userId = $_SESSION['user_id'];
session_write_close();

@Šaman právě o ty zbytečně útočné výpady mi jde, nemají tu co dělat (a zbytečně lidi stresují a potřebují dovolenou). A nepiš prosím offtopic příspěvky, jde přece založit nové vlákno.

Vzhledem k tomu, že potřebuji právě tuto věc implementovat do jedné aplikace, která je v Nette, logicky jsem sáhl po tomto rozšíření. Bohužel ale narážím na to, že i když mám nakonfigurováno podle README.md souboru z GitHubu, nefunguje to a nikde nemůžu najít žádnou ukázku jak to vlastně použít (kdyby to mělo aspoň testy…). Ne že bych byl v Nette úplný začátečník, ale nějak asi uniká, co s tím. Můžete mě odkázat na nějaké howto? Díky.