Problem s premennymi POST v hisorii – PHP – Fórum – Programujte.com

mam konkretny problem s premennymi POST. Ked sa chcem prihlasit na mojej stranke odosle sa formular na zaklade ktoreho databaza vyhodnoti ci su udaje spravne alebo nie. Ak ano tak ma prihlasi. Ked sa odhlasim a z historie prehliadaca vyberem stranku na ktorej som bol este pred odhasenim prihlaseny, vsetko je v poriadku... az na jednu stranku (tu na ktorej som bol tesne po prihlaseni) kliknem na nu z historie a prehliadac sa ma spyta ci chcem obnovit POST data ktore boli v minulosti odoslane. Ked dam ano, prehliadac priradi premennym $_POST['name'] a $_POST['password'] hodnoty z minula a automaticky ma prihlasi. A v tom je chyba ... Neviem co stym a najhorsie je ze neviem rozlisit ci boli data POST skutocne zadane alebo len obnovene z historie ... Keby som to vedel aspon by som tam dal podmienku ale ... (popripade ak viete inu metodiku prihlasovania resp. odhlasovania, rad sa poucim )

Mysl?m, ?e nep?jde nijak rozli?it zdali byla $_POST data z historie nebo zad?na u?ivatelem. Mo?n? by bylo dobr? se pokusit o to, aby st?nka nebyla ke?ov?na:

Header("Pragma: no-cache");

Header("Cache-Control: no-cache");

Header("Expires: ".GMDate("D, d M Y H:i:s",Date("U"))." GMT");

Z příspěvku mi nieje jasné, aký prihlasovací mechanizmus používaš?! Ale, tvoj problém by určite vyriešilo použitie session a nemusel by si riešiť problém s kešovaním.

dakujem za odpovede ... Pisal som uz selikde, ale nikto to nevedel ...
a teraz k odpovediam:
- inac ja pouzivam Session (teoriu a syntax viem) len ich neviem v tomto pripade vyuzit
- a neviem ako by mi pomoli session ked aj tak budem musiet dat na svoj web prihlasovaci formular, kde si uzivatel zada meno heslo a odosle to ...
a vtedy vznika problem s tymi premennymi post ...
- a ako to robi napr azet.sk alebo post.sk kde to funguje na 100%

Ak ovladate teoriu session, tak viete, ze session sa musi vytvorit, kontrolovat ci je platna a po "odhlaseni" z chranenej oblasti session treba (mala by sa) zrusit. A tymto sa dostavame ku korenu veci. Ak si aj browser nacita POST data, tak stranka se NESMIE zobrazit, pretoze session uz neexistuje. Vy mate zrejme cely kod napisany zlym sposobom, kde session mechanizmus je zle implementovany.

Maly nazorny priklad:
Mate stranku index.php v ktorej sa nachadza formular na zadanie mena a hesla. Po odoslani formulara si tato ista stranka overi zadane udaje s DB, ak suhlasia, tak sa vytvori session s identifikatorom (vacsinou ako konstanta SID), ktoru si musite pocas "pobytu" v chranenej oblasti prenasat napr. pomocou cookie a zaroven presmerujete na "chranenu" stranku admin.php. Na zaciatku kodu tejto stranky MUSITE overit, ci existuje a ci je zhodna session. Ak neexistuje/nieje zhodna/vyprsala, tak kod presmeruje uzivatela na stranku index.php, kde je prazdny formular (alebo uz su v nom napisane udaje v daka pomocke browsera).

Takze v historii si moze browser udrzat URL chranenej stranky v nasom priklade admin.php, ale kedze session neexistuje, tak uzivatelovi sa zobrazi index.php. A samozrejme, treba osetrit mnohe mozne zneuzitia session inym uzivatelom, pocas platnosti vasej "sukromnej" session (ale to uz je ina tema).

greppi, krom D1ce t? tu zat?m nikdo nepochopil... J? ano - v IE jsem toto tak? za??val a nen? to nic p?kn?ho. Nev?m, jestli to je i u dal??ch browser? na Windowsech, ale v GNU/Linuxu se mi to ji? nest?v?. nevím v?ak, jak by se toto dalo o?et?it. N?jak?m JS, kter? cosi p?id? do formul??e - to nem? smysl, browser pouze odes?l? ji? jednou odeslan? data...

Podle mne tedy jde o chybu browseru a z m?ho pohledu asi ani nep?jde vy?e?it (mo?n? ano, ale sp??e ne). Vyzkou?ej to i v jin?ch browserech. Pokud to d?l? jenom v tom jednom, tak bych se na to asi vyka?lal.

EDIT: Se sessions toto nem? nic spole?n?ho, proto?e kdy? se vr?t?? v historii, tak se v podstat? znovu p?ihla?uje? a sessions se znovu vytv???!!!

xHire - mas pravdu, pochopil si ma ...
... ale tak potom ked nie session, tak co?
... ako to vlastne riesia ine weby?
(inac tie funkcie header od D1ce mi nejako nefungovali, stale mi to nacitavalo premenne .... )

omg, ale ja som dobre pochopil v com ma problem a chcel som mu naznacit, ze ma napisany zly mechanizmus prihlasovania. Bezpecne prihlasenie sa do chranenej oblasti, nieje iba zadat meno a heslo, ale aj pomocne prvky, ako je napr. vygenerovany kontrolny retazec (ktory tam nieje iba preto, aby zdrzoval uzivatela).
Pekne sa to da ukazat na tom mojom priklade. Ked v historii kliknes na URL s admin.php, tak sa ti ziadne data z POST neposielaju a session neexistuje (ak uzivatel sa "poriadne" odhlasil), co znamena, ze budes presmerovany do prazdneho formulara index.php. A teraz druhy subor: ak v historii kliknes na index.php pri ktorom si browser vypyta potvrdenie o novozaslanie POST dat, tak maximalne sa uzivatelovi zobrazi hlasenie o zlom zadani prihlasovacich udajov! A preco, lebo kontrolny retazec je uz novy a stary neexistuje!

Skus trosku popremyslat a inak navrhnut zdrojovy kod!

Jasn?. Ty to zakl?d?? na tom, ?e znovuposlan? identifika?n? ?et?zec ji? byl jednou pou?it, a tud?? ji? je zaznamen?n v db jako pou?it?, tak?e ho aplikace odm?tne.

To ovšem ?e?? tento probl?m jen polovi?at?. :nn:?Pokud toti? prohl??e? bude data znovu odes?lat (v ne?ifrovan? podob?), tak nen? t??k? tato data odposlechnout :frosty_x: (na tom sam?m PC), a pot? se ji? korektn? p?ihl?sit.

Odposluch? Kiezby iba na tom samom PC! Ale neriesme tu nesifrovanu komunikaciu (ktoru jednoducho riesi SSL) a keyloggery, ktore zase riesi jednoducha vec - zdravy rozum! Zadavanie dovernych udajov v cudzom/nechranenom pocitaci sa neodporuca (to je predsa zakladne pravidlo pouzivania internetu)!

J? jsem nemyslel keyloggery - ty pouze odposlouch?vaj? stisknut? kl?vesy. J? myslel odposlouch?v?n? s??ov?ho provozu na s??ov? kart?.

P?edstav si, ?e p?ijde? n?kam na internet do kav?rny (?koly atd.). P?ihl?s?? se do n?jak?ho syst?mu, kde pracuje?. Pak se odhl?s?? a odch?z??. Jen?e pak n?kdo p?ijde, spust? odposlech, vr?t? se v historii, nech? si znovu poslat p?ihla?ovac? ?daje, a je to. Pravd?podobnost sledu t?chto ud?lost? je asi jako vyhr?t Sportku, ale je tady.

http://palisade.plynt.com/issues/2005Aug/browser-refresh/?- Přičemž první řešení se mi zdá jako lepší, protože není potřeba JavaScriptu.