I have a simple question. I know that I can prevent a form to re-submit itself when the user reloads the page by using the Post/Redirect/Get Pattern. But my question is, will this pattern work if I'm redirecting the user back to the same page where the form was submitted? I mean, I don't want to redirect the user to another page.
Any help please
Thank you
yes, but you have to remember to redirect him without the GET params.
so you can
header('Location: same_page.php?status=done');
die();
this way you are removing the param, and you need to support the status=done to show a message or what ever you want.
Related
PHP Post/Redirect/Get solution is good just for refreshing the page?
What about if the user clicks on the back button twice and resend the form? The only solution I have found is to check in my database if same data is already posted.
Is there any other solution without querying the database?
Thank you in advance!!!
PRG is perfect for browser Back button support too. An HTTP redirect replaces the URL in browser history instead of adding a new entry.
If you apply PRG consistently, i.e. you always return a redirect from a POST, then browser history will only contain "safe" pages (GET), there will never be a POST URL in the history.
There is still a chance of getting duplicate form submissions, though. For example if the user double-clicks the submit button. So if you want to be extra safe you need some extra mechanism (e.g. nonce) to prevent double submissions.
PRG is used because of the nature of HTTP. POST is not a safe operation hence PRG is preferred.
This question already has answers here:
How to prevent form resubmission when page is refreshed (F5 / CTRL+R)
(21 answers)
Closed 5 years ago.
I'm wondering if there is a way to stop pages from resending html forms when you refresh.
You could send a Location header to a different URL in your script that is processing the form input. This new URL will be available for the browser without the need to send form data.
It is principally impossible to stop a client (browser) over which you have no control, from doing something. It is however possible - and in your case quite easy - to harden your app against this:
When you show the form, create a random token, store it in the session and add it to the form as a hidden field
When you receive the filled-out form, check the token against the session, if it doesn't match ignore the data, if it does match clear the token from the session and process the data
Any headers or other tricks may or may not work with browsers and people refreshing WITHOUT MALICE, but they definitly won't help against an attacker.
Use Post/Redirect/Get: http://en.wikipedia.org/wiki/Post/Redirect/Get
in PHP process the form in code, then instead of outputting anything put this header('Location: http://www.example.com/foo.php'); (obviously replacing the url) and do the display on another page. If you need to pass anything to that page then use the query string and $_GET[]
I don't believe that there is a good way to do this. The way we have accomplished this in the past was to have a last_modified date and a minimum time between posts. If you haven't waited an hour say, the post would be rejected.
The only trick I know is to have the form submit return a page with a link that you click via javascript (meta refresh, whatever) to get you to a third page.
The idea being that the thing you end up refreshing when you hit F5 is the link page not the form submit page.
In my quest to solve this, I have been taking a bit of a different approach. In a self developed MVC environment I redirected the page twice. After making sure that the data is submitted to the database, I redirect it to
header("Location: http:// .... /redirect/blogcomment
This will call to my "redirect" class and the "blogcomment" method. Here it will get redirected again to the "referer".
public function blogcomment() {
$ref = $_SERVER['HTTP_REFERER'];
$page = "Location: " . $ref . "#commentform";
header($page);
}
This clears the POST array and by adding an anchor tag just in front of the form fields, I jump right back to that location. Of course I also gain a lot of freedom in customizing my redirect. So far it works like a charm.
Double load... i.e. redirecting the page back to itself is bad practice. Try debugging an app that does this and it makes it much more awkward to realize thi is happening. For the love of god people, if you have to php submit a form, send it to a separate script first, then back if you want to remove a refresh sending the form again, much easier to debug!
try doing :
unset( $_POST );
as last command.
What should be good way to redirect user after successful action like edit or delete any item, in delete condition we could use $_SERVER['HTTP_REFERER'] but in case of edit, we show first of all edit form and then user clicks update, so if we use same approach user would be redirected to edit page not main page. I hope you got idea about my confusion. thanks.
If 'update' is handled through a Form post, just put a hidden input in reflecting the landing spot.
<input type="hidden" name="next_url" value="foo.php" />
The PHP uses the value as the place to redirect to.
<?php
// Do operations.
header('Location: '.$_REQUEST['next_url']);
This is especially important because HTTP_REFERER is not guaranteed to work. It works most of the time, but there are issues with relying on it.
I advice to never use HTTP_REFERER.
It is possible it isn't set at all.
It can be anything, don't expect your previous page.
I advice an solid solution using (as above mentioned) hidden field, session storage, or simply have a solid routing in your application so you know which route someone took. Pick the best.
If you're OK with $_SERVER['HTTP_REFERER'] you can simply store that value in Session Information, and redirect to it when editing is finished.
For example, before showing the edit form you can do:
$_SESSION['originalReferer'] = $_SERVER['HTTP_REFERER'];
And after clicking "Update" (if successful):
header("Location: ".$_SESSION['originalReferer']);
But again, use this only if you trust $_SERVER['HTTP_REFERER'] !
Similar to the previous answer, I would suggest keeping track of the page you wish to redirect to using sessions., and then once you want to redirect, just use
header('Location: '.$redirect_var);
The reason why I would put it in the session, rather than posting in a form, is that form posting can be manipulated by the user, whereas sessions are server side, and are entirely under your own control.
Save the url in session when you are coming to Edit page and when you submit just use the below snippet after executing the update query:
header('Location: '.$_SESSION['redirect_url']);
I remember reading somewhere it's a good practice to redirect pages using GET to show the next page after a POST request. Why is it so?
This way, if the user reloads the page, the browser won't send another POST.
For example, if the page is an order confirmation page, you don't want the order to be repeated if the user refreshes the page.
It's because if a user submits a form and is taken to the thankyou page, then refreshes that page, the browser will prompt the user to resubmit the form, thus creating two posts to your data handler. If you redirect to the thankyou page with GET, the post vars are empty so the form won't be resubmitted.
I'm not sure it's still considered good practice - haven't heard anything on the subject for a while.
GET is idempotent while POST isn't. If the user reloads the page (or returns there by clicking the browser's Back button), nothing breaks.
I would assume this is so that the following page is bookmarkable.
If you can't remember why it's good practice then maybe there isn't a good justification for it.
IMHO, it's a case of swings and roundabouts - and certainly easy to argue the converse - whether its good practice or not really depends on how it fits in with the rest of your code.
C.
After submitting a form with post method f5 will resubmit that.
What's the best to avoid this without redirecting a page. Idon't like to disturb the user like this. Stackoverflow are immune to f5 but i don't see any redirection after asking a question.
Get After Post
Form does a POST request
Code processes form
Code redirects using Location header
Result: refreshing the resulting page will merely display it again, since it was done using GET.
StackOverflow is pretty AJAX-heavy, which is why you're seeing the behavior you see.
If you don't want to get all AJAXy, you want redirects. Redirects of this sort should be transparent to the user:
if (! empty($_POST)){
// Do something with the contents of $_POST
header('Location: success.php');
}
Now, if your validation fails, you probably reload the form with some error messages, and hammering F5 will re-POST the data. But if the operation is successful, the user will be redirected to your success page, and they can hammer f5 all day without rePOSTing data, and potentially creating duplicate actions.
The standard approach for achieving this effect is to use an HTTP redirect, which isn't obvious to the user (so I assume that you refer to a meta refresh delayed redirect).
See the Post Redirect Get pattern.