[PHP] Warning: Page Expiration

[Verwijderd]

Beste Tweakers,

Ik zit met het volgende probleem. Ik heb een website gemaakt, die gebruik maakt van sessions voor het onthouden van informatie die de gebruikers via forms weergeven naar andere pagina's. Dit gaat allemaal wel goed, maar zodra de gebruiker op de BACK knop zou drukken in de browser dan krijgt hij een lelijke witte pagina te zien met de volgende tekst:

"" Warning: Page has Expired The page you requested was created using information you submitted in a form. This page is no longer available. As a security precaution, Internet Explorer does not automatically resubmit your information for you.

To resubmit your information and view this Web page, click the Refresh button. ""


Ik gebruik voor mijn forms de POST method in plaats van GET. Dit ook omdat er Secure gegevens worden verstuurd.
Ik heb al overal gezocht op het net maar kan hiervoor geen oplossing vinden.

Zouden jullie me A.U.B hiermee kunnen helpen ?

[chem]

hier is geen oplossing voor volgens mij.

[Verwijderd]

Thug4Life: Ik gebruik voor mijn forms de POST method in plaats van GET. Dit ook omdat er Secure gegevens worden verstuurd.

<off-topic>
En waarom is een POST veiliger dan een GET ...?
</off-topic>

[chem]

Op donderdag 28 maart 2002 12:29 schreef Arien het volgende:

[..]

<off-topic>
En waarom is een POST veiliger dan een GET ...?
</off-topic>

je doet je sig al bijna eer aan Arien

't is idd onzin dat een post veiliger is...

[Belgar]

niet helemaal. de verstuurde Data is niet veiliger, maar met GET is er een grotere kans dat gevoelige informatie in de cache blijft staan en/of zichtbaar is voor andere mensen in de ruimte.

we hebben hier een systeem voor het bewerken van financiele informatie. Als je de login door bent krijg je een unique ID en die wordt CONSTANT met GET gepost op het scherm. De baas loopt ff van zijn werkplek, URLtje terugzoeken, emailen naar jezelf en wat denk je???

[ACM]

Op donderdag 28 maart 2002 12:32 schreef chem het volgende:
't is idd onzin dat een post veiliger is...

Evt kan je je het volgende bedenken:
met een password/username veldje krijg je bij GET:
pagina.php?user=blaat&pass=bladiebla
in je history (bij IE iig )

Met een POST komt dat er niet in. Op publieke PC's met een shared history is dat dus wel es erg vervelend (als je vergeet dat te verwijderen).

Maar verder?
[edit]
Zie reactie Belgar

[chem]

maar dat maakt de transport van de gegevens nog niet veiliger. Als je een sessie kan overnemen door enkel ergens een ander nummertje in te vullen, bij zulke gevoelige info dan deugt er toch iets niet in het systeem...

In principe zou het zo moeten zijn, dat als de data waar dan ook wordt opgevangen het geen enkele waarde heeft voor evt. afluisteraars...

[Grum]

Dit gedrag komt niet van je page af maar van de browser. De browser wil zelf niet nog eens het form submitten - zou lullig zijn als dat wel zou gebeuren namelijk.

Stel je voor dat het kan - je komt op een site - je koopt wat en op de pagina erna staat een javascriptje wat je 1 page terug je history inschopt. OOPS jah .. dan heb je het ineens 2x gekocht

[Verwijderd]

chem: Je doet je sig al bijna eer aan Arien

_{(Je kunt goed rekenen hoe laat het is en / of weet hoe veel ik nog moet doen voordat ik vakantie heb. )}

ACM: Met een password/username veldje krijg je bij GET:
pagina.php?user=blaat&pass=bladiebla
in je history (bij IE iig )

Dat is ook precies waarom je die pagina te zien krijgt: Open browser window? Even de back knop drukken en bingo.

Dus inloggen met POST, redirect^[1] en vervolgens een rij GETs. Problem solved.


^[1] Alhoewel de HTTP spec zegt dat je dan niet van methode mag veranderen (hier dus van POST naar GET) doen browsers dat wel, dus dat komt mooi uit.

[Verwijderd]

Ik denk dat je blij mag zijn dat dat ingebouwd is, want stel dat jij bv een pagina hebt gebouwd, waarop gegevens in een database worden gezet. Jij submit het formulier en alles wordt netjes opgeslagen. Nu is er iemand die de ballen verstand heeft van internet zo dom op op de back-button te klikken. Hij gaat dan dus terug naar de pagina waarop alles in de database gezet wordt, en je wordt weer doorgestuurd naar bv de bedank pagina. De persoon snapt het niet, en doet dit nog 100x voordat hij het beu is. Gevolg: er staat 101 keer dezelfde record in je database! Best irritant toch? Vandaar dat IE vraagt of je de pagina opnieuw wilt verwerken. Hier is dus niets tegen te doen.

[Tim]

Op donderdag 28 maart 2002 14:27 schreef Grote Vos het volgende:
Ik denk dat je blij mag zijn dat dat ingebouwd is, want stel dat jij bv een pagina hebt gebouwd, waarop gegevens in een database worden gezet. Jij submit het formulier en alles wordt netjes opgeslagen. Nu is er iemand die de ballen verstand heeft van internet zo dom op op de back-button te klikken. Hij gaat dan dus terug naar de pagina waarop alles in de database gezet wordt, en je wordt weer doorgestuurd naar bv de bedank pagina. De persoon snapt het niet, en doet dit nog 100x voordat hij het beu is. Gevolg: er staat 101 keer dezelfde record in je database! Best irritant toch? Vandaar dat IE vraagt of je de pagina opnieuw wilt verwerken. Hier is dus niets tegen te doen.

Ik neem aan dat je dat ook controleerd voor je iets toevoegd aan je DB

[Verwijderd]

Thanks voor al die informatie.
Als ik het goed begrijp is er dus hieraan niets te doen.

Als ik dus een login/password pagina heb, en ik post die gegevens naar een andere pagina zodat die hem dan checkt in de database zou je dus geen back mogen drukken anders krijg je die "expiration pagina" .
Maar toch zijn er vele php sites waarbij je kunt inloggen en dan toch op Back drukken zonder die "warning" pagina te krijgen . Hoe zouden zij dat dan doen?

Alvast bedankt

[Belgar]

JAVAscript, waarschijnlijk. De warning wordt gegenereerd door je FORM. en de submit daarvan. Als je dit met variables en javascript afhandeld is het misschien mogelijk.

[JayTaph]

Het heeft een reden waarom PHP dit zo oplost. Je namelijk niet met je back-button terug naar een oud form (van iemand) anders om wat data aan te passen en opnieuw te submitten. Als je zorgt dat je bij elke form-submit (of eigenlijk elke aanroep van een php-script) even kijkt of er een session bestaat, dan hoeft dit helemaal geen probleem te zijn.

Een hele makkelijke oplossing:

in je php.ini file de variabele session.cache.limiter veld LEEG maken.

En je kunt nu wel je back-button gebruiken om door je forms te scrollen.

[Verwijderd]

Ik heb dus hetzelfde probleem momenteel als de topicstarter, nu wilde ik proberen of het wel werkt wanneer je een var mee terug kan geven.

Dus ik wilde de volgende dingen combineren:

commited=yes
EN
javascript:history.go(-1)

[Verwijderd]

Verwijderd schreef op 28 maart 2002 @ 12:26:
Ik zit met het volgende probleem. Ik heb een website gemaakt, die gebruik maakt van sessions voor het onthouden van informatie die de gebruikers via forms weergeven naar andere pagina's.

Ik vindt dit eerlijk gezegt wel heel breed omschreven.
Als we bijvoorbeeld over inloggen praten, kun je best a la React ( GoT ) een refresh doen.

Als je het over een stappenplan hebt (bijvoorbeeld een winkelwagen of iets dergelijks) dan moet je je code zó schrijven dat er niets mis kán gaan.
Dus goede controles van de POST variabelen en het zó maken, dat als men wel op refresh drukt, er eigenlijk niets misgaat. Dus dat of de waarden opnieuw in de sessie worden gestopt, of dat er niets gebeurd.
Zo kun je bijvoorbeeld controleren of een sessie al gezet is, zo niet dan kun je de eventuele POST var's erin stoppen en zo wel, dan doe je lekker niets.

Het is maar wat je wilt, en wat het resultaat moet zijn.
In mijn opinie..

[Verwijderd]

Oke, ik zal proberen het zo goed mogelijk te beschrijven. Ik ben dus bezig met een applicatie waarin quarantaines (qualiteits afwijkingen aan producten) ingevoerd gaan worden.

Deze records worden ingevoerd in een database en kunnen op een bepaalde pagina worden opgevraagd per x aantal resultaten en kunnen daar ook worden gesorteerd.

Wanneer er vervolgens op een record wordt geklikt wordt het record weergegeven. Vanaf deze pagina wil ik dan ook op vorige kunnen klikken en daarbij de sorteer instellingen behouden.

Hoop dat dit duidelijk genoeg is.

[ripexx]

Waarom verwerk je deze acties dan via POST, sorteer volgorde enz doe ik in ieder geval altijd via een GET. POST gebruik ik vooral als ik inserts, updates enz doe waarna ik direct een redirect doe. Zodoen voorkom je het back probleem.

Anders moet je gebruik maken van een cookie. Hoe je het ook bekijk je zal er toch wat voor moeten aanpassen.

[Verwijderd]

Klopt,
door het gebruik van de GET wordt de informatie inderdaad vastgehouden, bedankt voor de tip.

[.oisyn]

Zou je voortaan een nieuw topic willen openen (met evt. een linkje naar deze topic) ipv een hele oude topic te kicken? Het is namelijk nogal verwarrend (zie bijvoorbeeld ivy die op een hele oude reactie reageert). Je hoeft overigens nu niet alsnog een nieuwe topic te openen, alle info die je nodig hebt staat namelijk al in deze topic

Het kan dus niet met POST, zoals al gezegd is

[ Voor 34% gewijzigd door .oisyn op 19-03-2004 15:07 ]