[php] controleren of de pagina gerefreshed is.

[Verwijderd]

Ik wil een php document schrijven die aangestuurd wordt door middel van een form. maar nu wil ik het zo dat wanneer de pagina ge-refreshed wordt dat hij niet opnieuw de form data verstuurd, of dat ik aan het begin van de php een check kan zetten die ziet of de pagina gerefreshed is.

ik heb het op dit moment dmv een javascript. bij onsubmit set hij een variabele in de sessie data, en bij de eerste keer ophaln van de pagina, un-set hij die weer. wanneer er dan op f5 gedrukt word ziet het script dat die variabele niet meer geset is en dus weet hij dat het een gerefreshde pagina is...

maarja ik ben geen js fan(ivm browser compatibility) en het lijkt me dan toch ook wel dat het mogelijk moet zijn in php om dit te doen?

[Erkens]

Na de POST een redirect doen (naar een andere URL) en na een refresh heb je geen last van het opnieuw posten meer

[RomeoJ]

Dan zet je toch in de Form URL een ?post=true ofzoiets erachter. Zo kan je het met een PHP script opvangen en weet je dus dat de Form al verzonden is.

Dat lijkt me een makkelijke manier om je probleem op te lossen.

[StevenK]

Verwijderd schreef op maandag 22 januari 2007 @ 12:52:
maarja ik ben geen js fan(ivm browser compatibility) en het lijkt me dan toch ook wel dat het mogelijk moet zijn in php om dit te doen?

header('location: /index.php'); of iets in die richting ?

[Erkens]

R3dn3ck schreef op maandag 22 januari 2007 @ 12:58:
Dan zet je toch in de Form URL een ?post=true ofzoiets erachter. Zo kan je het met een PHP script opvangen en weet je dus dat de Form al verzonden is.

Dat lijkt me een makkelijke manier om je probleem op te lossen.

Dat gaat natuurlijk nooit werken aangezien die ook met een refresh mee gestuurd wordt

[RomeoJ]

Ik dacht dat hij bedoelde dat het refreshen van een pagina tijdens de submit van een Form was. Dat het Form naar dezelfde pagina verwijst en dus refreshed.

* Maar okee zo simpel zal het inderdaad wel niet zijn want dat kan je met veel nettere en makkelijkere oplossingen bewerkstelligen.

[ Voor 30% gewijzigd door RomeoJ op 22-01-2007 13:04 ]

[Cartman!]

PHP:

unset($_POST);

werkt altijd prima na het uitvoeren van de dingen waarvoor je de POST vars nodig had. Na een refresh is dat dus weg en zou de gebruiker het form weer te zien krijgen.

[Erkens]

Cartman! schreef op maandag 22 januari 2007 @ 13:07:

PHP:

unset($_POST);

werkt altijd prima na het uitvoeren van de dingen waarvoor je de POST vars nodig had. Na een refresh is dat dus weg en zou de gebruiker het form weer te zien krijgen.

Weet je uberhaupt wel wat unset doet? iig niet de POST variabelen aan de client kant verwijderen

[Cartman!]

je hebt gelijk ben in de wat met sessies, maandag eh?

edit:

je kan na de post in een sessie var bijhouden dat er gepost is en daarop checken bij t inladen van de page. Als die var op TRUE staat ga je niet posten dus. Als iemand het form zelf opnieuw aanroept zet je em weer op FALSE.

[ Voor 66% gewijzigd door Cartman! op 22-01-2007 15:00 ]

[Olaf van der Spek]

Cartman! schreef op maandag 22 januari 2007 @ 14:58:
je kan na de post in een sessie var bijhouden dat er gepost is en daarop checken bij t inladen van de page.

Waarom moeilijk doen in plaats van de eenvoudigere en betere oplossing van Erkens implementeren?

[pietje63]

Omdat als je dan een pagina terug gaat in je historie nog steeds het probleem hebt?

Volgens mij kijkt bijv. de React gewoon of je net al dezelfde post gemaakt hebt, zo ja, dan krijg je een melding dat je aan het dubbelposten bent.

[Olaf van der Spek]

pietje63 schreef op maandag 22 januari 2007 @ 17:29:
Omdat als je dan een pagina terug gaat in je historie nog steeds het probleem hebt?

Welk probleem?

Dan ga je terug naar de pagina met het form en kan de gebruiker het eventueel handmatig nog een keer submitten. Maar dat heeft niks met refreshen te maken.

[Erkens]

pietje63 schreef op maandag 22 januari 2007 @ 17:29:
Omdat als je dan een pagina terug gaat in je historie nog steeds het probleem hebt?

Volgens mij kijkt bijv. de React gewoon of je net al dezelfde post gemaakt hebt, zo ja, dan krijg je een melding dat je aan het dubbelposten bent.

dat doet React _ook_ ja, maar ook die redirect, probeer na een POST maar eens op F5 te duwen, je zal dan namelijk niet alsnog die POST doen, maar een normale GET request.

[Cartman!]

Volgens mij als je dan op de back button drukt krijg je wel weer de vraag of je wilt posten namelij. Door in een sessie dit te ondervangen zou je direct zorgen dat de info niet nog een keer gesubmit word ipv checken of die data t zelfde is.

[wackmaniac]

Ik zou twee maatregelen nemen:
1. Na het succesvol posten naar een andere pagina sturen mbv header('Location: success.php');
2. Controleren of de post gelijk is aan een andere zeer recente post

Dan zou je het wel aardig voor elkaar moeten hebben. Maar als je het echt wilt controleren zou je een identifier mee kunnen sturen met het formulier, maar dat is misschien weer een beetje te veel van het goede.

[tyrion70]

Okee.. ff snel getest.. Maar een header(Location.....) zorgt ervoor dat bij het klikken op de back button je terug gaat naar de laatste pagina (aan de client kant!) Deze houdt dus geen rekening met de 303 redirect die de header() veroorzaakt...

Maw:

index.php

PHP:

<form action=index2.php method=post>
<input type=submit>
<input type=text name=test>
</form>

index2.php

PHP:

<?
if ($_POST['test']) {
  header("Location: index3.php");
}
?>

index3.php

PHP:

echo ''verstuurd'';

Geeft bij submitten van het formulier netjes verstuurd weer (van index3.php), maar bij het klikken op de back button gaat ie terug naar index.php.

dus:

index.php post naar index2.php

index2.php -> 303 -> index3.php

index3.php -> back -> laatste geladen pagina = index.php

HTH

[Olaf van der Spek]

Cartman! schreef op maandag 22 januari 2007 @ 19:46:
Volgens mij als je dan op de back button drukt krijg je wel weer de vraag of je wilt posten namelij.

Nope.

tyrion70 schreef op maandag 22 januari 2007 @ 20:15:
Okee.. ff snel getest.. Maar een header(Location.....) zorgt ervoor dat bij het klikken op de back button je terug gaat naar de laatste pagina (aan de client kant!) Deze houdt dus geen rekening met de 303 redirect die de header() veroorzaakt...

Dat is toch precies de bedoeling?

[ Voor 47% gewijzigd door Olaf van der Spek op 22-01-2007 20:39 ]

[Frunnik]

Query naar DB, of er de afgelopen XX (limiet) door deze user een post is gemaakt.
Gebruik daarbij time(); http://nl2.php.net/time

Je kunt die Query bovenaan de make_post.php zetten. (Bij een back + refresh laat je dan gewoon een error zien)

Of je zet de query op de post_in_dbzetten.php (Controleren of die al is gemaakt, zoniet... ff errortje)


// OPTIE 2

Hidden field in je html opnemen, met een gegenereerde code.
(Bestaat deze al, is het een repost)

[ Voor 60% gewijzigd door Frunnik op 22-01-2007 20:50 ]

[tyrion70]

Olaf van der Spek schreef op maandag 22 januari 2007 @ 20:37:
[...]

Nope.

[...]

Dat is toch precies de bedoeling?

Idd.. ik bedoelde ook te zeggen dat jij gelijk had Ik probeerde alleen met een simpel (door iedereen te simuleren) voorbeeldje aan te tonen dat het probleem waar Cartman en Pietje het over hadden dan niet ontstaat.. Je kunt dan dus idd veilig op de back button klikken..

[Verwijderd]

ik ga die redirect er even in zetten. tnx voor de reacties