Vlastne session riesenie – PHP – Fórum – Programujte.com

Caute, 

pohravam sa s myslienkou zavrhnutia vstavaneho riesenia session v PHP a postavit vlastne (napr. v DB alebo klasika subory). 

Stve ma ta "nekonzistencia" dat na roznych serveroch, hostingoch. Na localhoste doma mi ide vsetko ako ma, ale niekde proste vyprsi session skor ako mam nastavene (asi kvoli nejakym internym nastaveniam hostingu).

Mam napr. ulozeny token proti csrf v session, uzivatel si pootvara stranky, medzitym ide na obed... vrati sa, vyplni formular, odosle a samozrejme csrf token nesedi lebo session uz neexistuje.. a mne sa to fakt zle vysvetluje laikovi preco...

Riesi niekto z Vas session po svojom, a ak ano, tak ako?

Dik

#1 majo
Standardně bývá platnost session omezena na 25 minut a na hostingu to nejspíš nezvýšíš - můžeš to jen snížit.

PHP nabízí rozhraní pro vlastní správu session. Můžeš k tomu využít třeba MySQL, ale zajímavým řešením by mohl být i Redis. Používá se to zejména tam, kde potřebuješ jednu sadu sessions pro více serverů.

Je však velmi jednoduché omezenou platnost sessions obejít: Stačí mít na stránce nějaké periodické ajaxové volání skriptu s otvíráním sessions a dokud uživatel nezavře stránku, sessions je chráněno.

ano, je to cca tych 25 - 30 minut, to je k vzteku, ked toto clovek nedomysli hned na zaciatku.. redis je bez sance na hostingu, ale tusim ze memcache tam je, a ten by siel pouzit..

rozhranie myslis fc. session_set_save_handler ?

to periodicke volanie session_start ma napadlo tiez, ale tam je zas problem, ze kvoli takej "malichernosti" zatazujem server.. 

no nic, idem to asi prerabat :(

#4 majo
To není žádná zátěž serveru. Nevím, jakou máš aplikaci, ale obvykle stejně potřebuješ aktualizovat počitadlo přijatých zpráv, stav košíku apod. Je to přenos jen pár desítek bajtů, nejedná se o překreslení celé stránky.

ok, berem, az taka zataz to nie je.. ale stale ostava problem, ak sa mu uspi pocitac, resp. ho vypne a po zapnuti mu prehliadac predhodi cache stranky a nepoziada o novu.. 

dalo by sa to vyriesit napr. s localStorage, ale aj tak to moze uzivatela zmiast.. minimalne hlaska v zneni "Vase data system povazuje za nedoveryhodne, zaslite formular znovu"..

sam si programator, urcite aj ty preferujes nepriestrelne riesenia s tym, aby com najmenej obtazovali BFU

#6 majo
To se dělá právě tím ajaxem. V tom případě můžeš mít domovskou stránku statickou a cache neřešíš.

Pro každý Use Case se to dělá jinak. O tvém projektu nic nevím, takže ti ani nemohu poradit nejvhodnější řešení. Nemám tušení, zda nakonec nebudeš potřebovat třeba WebSocket.

Neznám větší noční můru, než špinavé cache. Proto je v aplikacích nevytvářím.

session vyuziva jadro systemu najma na svoj vlastny chod.. nie su tam ziadne kosiky atd... 

jadro systemu vlastne zabezpecuje aplikaciam ktore su nad nim postavene (eshop, cms... , proste cokolvek) , to, ze vsetky data ktore pridu z vonku (a ktore su don posielane) su konzistentne a nepozmenene (csrf tokeny, podpisuje a overuje podpisy cookies, kontroluje poziadavky z url..........) a ak je vsetko v cajku, routne url a spusti aplikaciu a posle jej potrebne data. 

a nebude v mojom pripade dobre ak sa bude aplikacia "starat" do jadra (volaniami ajaxom).. ona o nom by ani nemala vediet ze existuje.. su od seba oddelene.. ked vyprsi session, poziadavka uzivatela neprejde teda jadrom a poziadavka sa tvari ako nedoveryhodna.. 

Kdysi jsem nekde v php nasel nastaveni adresare pro session a i cas tam sel menit. Ale sel bych do toho sql, spis.

#9 peter
Proč ne do NoSQL?

Nevim, co myslis. Se soubory by se mi drbat nechtelo. To zalezi na hostingu, jaka ma omezeni, diskovou kapacitu, pocet sql dotazu a tak.
Kdyz na serveru presmerujes kes na svuj hosting, do slozky a serverak vsechny slozky presune na ssd, tak asi brzo to ssd odejde.Jakoze si nejsem jisty, ze by tak do hloubky kazdemu uzivateli kontrolovat, kde a jak resi session. U sql s tim asi nejak pocitaji, ze se tam muze sypat jeden dotaz za druhym.

#11 peter
Například Redis jede jen v paměti a zvládne o 1-2 řády větší zátěž než databáze SQL.

refaktoroval som to do mysql, a nemozem vynachvalit.. ziskal som viac moznosti pracovat z relaciami.. otestoval som aj "vykon" oproti klasickym suborom a je to dokonca rychlejsie..

vygeneroval som 200 000 zaznamov v tabulke a cas na ziskanie dat z DB je zanedbatelne vacsi o asi 10ms oproti session suborom.. a realne v praxi tych 200k sedeni ani nebude..

Jsi si jisty, ze tam mas spravne indexovani? 10 ms je takovy bezny cas pro sql dotaz na localhostu. Servery by meli vladat vic.
https://i.stack.imgur.com/OoF58.png
https://i.ytimg.com/…sdefault.jpg
https://i.stack.imgur.com/BUQ5n.png

tych 10ms je priemerny rozdiel medzi verziou s klasickymi session (takmer ziadnymi vytvorenymi) a session v DB (200k ulozenych relacii)... system na "obhospodarovanie" relacii som urobil vlastny, cize zabudovane funkcie uz nevyuzivam.. podla mna zanedbatelne..

session id vytvaram takto: ID - CODE , kde ID je primarny kluc v tabulke a CODE je nahodny retazec ktory overim az po ziskani zaznamu podla ID.. 

#15 majo
10 ms je hodně, to je třetina celkové odezvy serveru. Do toho bych nešel.

ale tych 10ms je meranych pri praci s 200 000 ulozenymi relaciami.. to je extrem, taka situacia nikdy nenastane (ak ano, vtedy uz budem milionar :D ) .. ako spomalenie by nastalo pri 200 000 klasickych session suboroch? bez uprav by to ani len nenacitalo subor.. 

momentalne pri ulozenych cca 10 relacii nie je ziadny rozdiel (resp. nie je ani meratelny)

ok nedalo mi to, premeral som to znova, nahral som 300 000 relacii (nahodne generovane data).. asi som predtym urobil nejaku chybicku, ktoru som nevedomky opravil, lebo teraz mi pri tomto pocte nespomaluje vobec.. je to plus minus to iste.. 

tabulka ma 300k zaznamov a je velka 201MiB

#17 majo
U databáze není rozdíl, zda máš uloženo 10 relací nebo 10M relací. Nezapomněl sis náhodou udělat index?

ano, zrejme som vtedy nemal urobeny index.. lebo uz je to absolutne ok :)

Tezko rici z toho, jak to popisujes, co tam vlastne mas, ale...
id, code, time
index id, index code 3 znaky, index time
- pro hledani kodu by mohli prvni 3 znaky pomoci, ale mozna bude treba upravit i sql dotaz
- indexovani casu se myslim tez hodi, kdyz budes session rusit pres script v cronu. Ne kazdy uzivatel klika odhlasit se, protoze to normalni session udelaji, kdyz zavres vsechna okna prohlizece. Ale i kdyby tam 1 zbylo, tak spousta lidem je to fuk.

kod je zbytocne hladat.. v cookies je ulozene 151-hbhjHJbjhHJbHJbjh6556fee (symetricky zasifrovane pre istotu, ak by doslo ku kompromitacii DB) , ja si s toho zoberem cislo pred pomlckou (spojovnikom) a hladam v DB iba podla toho.. najdem vysledok a ten porovnam ci suhlasi zvysok za pomlckou.. ak ano, nastartuje sa relacia.. jedna z viacerych vyhod je napr. znemoznenie session fixation, pretoze utocnik nedokaze podhodit ziadny session id tak aby ho system akceptoval..

cas indexujem tiez :)

#23 majo
Čas bys asi indexovat neměl, nevidím k tomu důvod.

cize indexovanie casu (datetime) to nijak neurychly? ak nie tak indexaciu vypinam..

(indexovaniu okrem primarneho kluca a unique moc nerozumiem :( )

#25 majo
Indexování času v daném případě spíše jen zpomalí práci s databází.

K čemu je dobrý sloupec id? Nestačil by jen sloupec code? Sloupec id bych zcela zrušil.

potrebujem na tej tabulke primarny autoincrement kluc , este k jednej pripravovanej veci.. preto som ju zaroven vyuzil.. vyhladavanie bude rychlejsie hadam v int ako v char(32) nie?

#27 majo
Spíš naopak. Sloupce s autoincrementem používají pro INDEXování B-stromy, proto jsou z principu pomalejší než UNIQUE nad hashem.

Jako klíč pro takovou tabulku zcela vyhovuje: code CHAR(32) PRIMARY KEY

Navrhoval jsem indexovat sloupce, ktere bych pouzival ja. Jakym zpusobem je vyuzivas ty, podle toho indexuj. Vetsinou se indexuje vse, co pouzivas pro podminky WHERE.

#29 peter
Každý index, který je navíc, zpomaluje INSERT. Pokud podmínce ve WHERE vyhovuje víc než cca 10 % záznamů, index to nijak neurychlí.