Vlastne session riesenie – PHP – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

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

 

Spuštěný nový filmový web Filmožrouti.cz — vše o Avengers, Pacific Rim, Thor, Star Wars…
majo
~ Anonymní uživatel
70 příspěvků
18. 11. 2017   #1
-
0
-

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

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
18. 11. 2017   #2
-
0
-

#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.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
18. 11. 2017   #3
-
0
-

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 ?

Nahlásit jako SPAM
IP: 188.123.100.–
majo
~ Anonymní uživatel
70 příspěvků
18. 11. 2017   #4
-
0
-

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 :(

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
18. 11. 2017   #5
-
0
-

#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.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
18. 11. 2017   #6
-
0
-

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

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
18. 11. 2017   #7
-
0
-

#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.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
18. 11. 2017   #8
-
0
-

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.. 

Nahlásit jako SPAM
IP: 188.123.100.–
peter
~ Anonymní uživatel
3027 příspěvků
20. 11. 2017   #9
-
0
-

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

Nahlásit jako SPAM
IP: 2001:718:2601:258:4135:5e...–
Kit+12
Guru
20. 11. 2017   #10
-
0
-

#9 peter
Proč ne do NoSQL?

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
peter
~ Anonymní uživatel
3027 příspěvků
20. 11. 2017   #11
-
0
-

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.

Nahlásit jako SPAM
IP: 2001:718:2601:258:4135:5e...–
Kit+12
Guru
20. 11. 2017   #12
-
0
-

#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.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
28. 11. 2017   #13
-
0
-

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..

Nahlásit jako SPAM
IP: 188.123.100.–
peter
~ Anonymní uživatel
3027 příspěvků
28. 11. 2017   #14
-
0
-
Nahlásit jako SPAM
IP: 2001:718:2601:258:c4ce:4c...–
majo
~ Anonymní uživatel
70 příspěvků
28. 11. 2017   #15
-
0
-

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.. 

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
28. 11. 2017   #16
-
0
-

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

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
28. 11. 2017   #17
-
0
-

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)

Nahlásit jako SPAM
IP: 188.123.100.–
majo
~ Anonymní uživatel
70 příspěvků
28. 11. 2017   #18
-
0
-

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

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
28. 11. 2017   #19
-
0
-

#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?

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
28. 11. 2017   #20
-
0
-

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

Nahlásit jako SPAM
IP: 188.123.100.–
peter
~ Anonymní uživatel
3027 příspěvků
29. 11. 2017   #21
-
0
-

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.

Nahlásit jako SPAM
IP: 2001:718:2601:258:282b:47...–
majo
~ Anonymní uživatel
70 příspěvků
29. 11. 2017   #22
-
0
-

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..

Nahlásit jako SPAM
IP: 188.123.100.–
majo
~ Anonymní uživatel
70 příspěvků
29. 11. 2017   #23
-
0
-

cas indexujem tiez :)

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
29. 11. 2017   #24
-
0
-

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

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
29. 11. 2017   #25
-
0
-

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

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

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
29. 11. 2017   #26
-
0
-

#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.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
majo
~ Anonymní uživatel
70 příspěvků
29. 11. 2017   #27
-
0
-

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?

Nahlásit jako SPAM
IP: 188.123.100.–
Kit+12
Guru
29. 11. 2017   #28
-
0
-

#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

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
peter
~ Anonymní uživatel
3027 příspěvků
30. 11. 2017   #29
-
0
-

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.

Nahlásit jako SPAM
IP: 2001:718:2601:258:c0e3:2b...–
Kit+12
Guru
30. 11. 2017   #30
-
0
-

#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í.

Nahlásit jako SPAM
IP: 194.228.68.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Zjistit počet nových příspěvků

Přidej příspěvek

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 34 hostů

Podobná vlákna

Riesenie problemu s obejktom — založil SVKSuli

Vlastne GUI — založil stanke

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032017 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý