Door
Dennis WhoCares
op 08-02-2016 20:53
gewijzigd op 08-02-2016 21:01
1.785 views
Dag allemaal,
ik ben nou heel ijverig bezig met aantal replies via jquery.
Alleen... Weet niet goed wat ik moet kiezen..
Moet ik nou met GET gaan werken of met POST?
Waarop overweeg je dit, ik gebruik geen formulier, maar gewoon een plaatje/button om een ID toe te voegen aan een database, dus ga ik gewoon voor GET toch?
Op basis van json result laat ik een 'popup' zien.
De eindgebruiker zal dit nooit zien, tenzij ze de broncode gaan pluizen, dan vinden ze jquery met de request, waarbij ze ook nog ff in de html moeten puzzelen wat de link wordt, of gewoon een alert geven dmv firebug ofzo ;-) maar het wordt allemaal goed gecontrolleerd en afgevangen
Whatever floats your boat. In dit geval maakt het niet zoveel uit omdat jQuery het request doet? Als een gebruiker dit in een aantal stappen doet zou ik gaan voor POST, volgens het POST, REDIRECT, GET principe zodat "dubbel posts" uitgesloten zijn.
En als je zoekfunctionaliteit maakt middels een formulier is GET weer handiger (je kunt de zoekopdracht bookmarken, zonder problemen hier naar terugnavigeren in je history et cetera).
Whatever floats your boat. In dit geval maakt het niet zoveel uit omdat jQuery het request doet? Als een gebruiker dit in een aantal stappen doet zou ik gaan voor POST, volgens het POST, REDIRECT, GET principe zodat "dubbel posts" uitgesloten zijn.
En als je zoekfunctionaliteit maakt middels een formulier is GET weer handiger (je kunt de zoekopdracht bookmarken, zonder problemen hier naar terugnavigeren in je history et cetera).
Wat handig is zou moeten blijken uit het gebruik.
Ik snap de PRG niet helemaal :-/ kan aan mij liggen uiteraard
Stel ik heb een bestelling. [P]ost. En ik accepteer betaling, of bevestig w.e.
Dan gaat de server bijv. de cookie wegschrijven naar database.
Zou de server dan met een header location [R]edirect moeten antwoorden?
Zodat de gebruiker weer naar de juiste pagina gaat, bijv.. betalingsgevens invoeren.
Ik gebruik eigenlijk 9/10 keer altijd header redirect's.
Wat heeft de [G]et er nog mee te maken dan ?
Of is het hele idee hierachter gewoon om je 'server-side actions' te beperken en zo kort mogelijk te houden zodat deze zsm alles afhandeld (wat altijd de bedoeling is)
Moet ik met een
'303 See Other' header de 'update' pagina laden? (welke de submit knop bevat)
GET kun je vertalen als 'ophalen' en POST als 'data naar het systeem verzenden'.
De stelregel is dat je een GET request uitvoert om gegevens op te halen en te tonen (bijv. een overzicht met producten) en dat je een POST request uitvoert op het moment dat je data gaat manipuleren (bijv. een database record toevoegen, verwijderen of updaten). Hetgeen wat jij doet, het toevoegen van een ID aan de database, zou dus moeten plaatsvinden via een POST request.
Ooit na het versturen van een formulier op F5 (pagina vernieuwen) gedrukt? De meeste browsers zullen vragen of ze de data nogmaals mogen versturen. Klik je op ja dan heb je ineens twee items in je winkelwagen in plaats van één.
Volgens mij legt dat artikel het erg ingewikkeld uit. Wat ik iig doe is het volgende:
Ik voeg een CSRF token toe aan al mijn formulieren. Het CSRF token wordt tevens in de session opgeslagen.
Als een gebruiker het formulier verstuurd dan wordt het CSRF token in de POST data vergeleken met het CSRF token in de session. Als deze hetzelfde is dan wordt het formulier verwerkt (database bijwerken, email sturen en redirecten) en het CSRF token wordt uit de session verwijderd. Als het CSRF token niet hetzelfde is dan krijgt de gebruiker een foutmelding te zien en wordt het formulier niet verwerkt. Hierdoor is een ongewenste dubbele verwerking van het formulier al (zo ver ik weet) uitgesloten. Zoals gezegd wordt de gebruiker ge-redirect naar een andere pagina nadat het formulier verwerkt is. De gebruiker krijgt hierdoor een nieuwe pagina te zien die niet meer in de POST methode maar in de GET methode aangeroepen is. Vandaar PRG.
<?php
session_start();
// initialisatie
$errors = array();
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
// validation
if(!isset($_POST['_TOKEN']) || !isset($_SESSION['_TOKEN']) || $_POST['_TOKEN'] != $_SESSION['_TOKEN'])
{
$errors['_TOKEN'] = 'Wrong CSRF token. Try again.';
}
/* hier nog meer validatie van de gewone formuliervelden */
// verwerk het formulier als de validatie geslaagd is
if(!count($errors))
{
// token is gebruikt en ongeldig geworden dus verwijder maar uit de sessie
unset($_SESSION['_TOKEN']);
/* hier je INSERT, UPDATE of DELETE database query */
// redirect de gebruiker en beeindig het script hier
header('Location: thankyou.php');
exit;
}
}
$token = uniqid(); // dit kan beter maar dit is ter illustratie om het simpel te houden
$_SESSION['_TOKEN'] = $token;
?>
<DOCTYPE!>
<html>
<head>
<meta charset="UTF-8">
<title>My form</title>
</head>
<body>
<?php
if(count($errors))
{
echo '<ul>';
foreach($errors as $error)
{
echo '<li>' . $error . '</li>';
}
echo '</ul>';
}
?>
<form action method="post">
<!-- hier je normale formfields -->
<input type="hidden" name="_TOKEN" value="<?php echo $token; ?>">
<button type="submit">Verzenden</button>
</form>
</body>
</html>
Ook een goede tip Frank!
Toch ben ik nog wel benieuwd naar de PRG protocol, snap er geen snars van xD
Uiteraard komt er een redirect na mn post, maar... dat is pas als je pagina klaar is met laden, als je in tussentijd refresh klik.. dan zit je nog steeds dezelfde pagina te laden.
In Frank zn voorbeeld, zal je de sessie gelijk als eerste moeten xontrolleren en direct verwijderen, anders krijg je nog steeds dubbele posts
In Frank zn voorbeeld, zal je de sessie gelijk als eerste moeten xontrolleren en direct verwijderen, anders krijg je nog steeds dubbele posts
Je zou dit kunnen zien als onderdeel van formulier-validatie, dus dat zou je eigenlijk sowieso moeten doen. Het token-veld is ook gewoon input; alle input dient gevalideerd te worden.
