There is a form ,which is submitted and then the page is redirected to another page.But if the user hits the refresh button again on the new page .the following message is displayed
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
And on press "OK"
A duplicate entry is created how do i prevent this or how do i handle this
I am using a django,application
Thanks..
I would double check your sequence of events because it seems like something is off.
It sounds like you're processing the post data, then returning an HTTP response rather than a redirect. When your user refreshes the page they resend the POST data.
I'm wondering where and when are you processing the POST data and if you're correctly redirecting.
The page that the form submits to should process the POST data and create an entry (sounds like that is working).
If you want to avoid having the double post issue on a successful submission it's best to redirect to another page AFTER you've processed the data and successfully saved.
This will not pass the POST data to the new view, and the user can refresh the page to their hearts content without having to worry about double submissions.
Related
Say, I have a simple form on my website having three fields : name, password and email.
I have to get these information from the users, and keep in my database.
Then redirect to another website and send all these information using post.
I also have to know whether the user was successfully redirected to that site(HTTP STATUS 200).
Here's how I'm doing it:
For Point 1, I'm simply submitting the form.
After the data has been successfully saved in my database, I'm rendering the following form with hidden fields. This gets submitted and user gets redirected to anotherwebsite.com
<form id="form_id" action="https://www.anotherwebsite.com/form" method="POST">
<input type ="hidden" name ="name" value ="$name">
<input type ="hidden" name ="password" value ="$password">
<input type ="hidden" name ="email" value ="$email">
</form>
<script> document.getElementById('form_id').submit(); </script>
Problems:
I don't think my strategy to achieve point 1 and 2 is correct. I need a better solution. Submitting the form, then rendering a page with hidden fields and submitting it again to redirect to another site just doesn't feel right.
I have no clue to achieve the 3rd point.
Based on your question you might try this approach:
create a form with name, password, email fields in a file ( HTML ).
Submit the form to server.
On the server side get the data (including the form attribute in a variable) and save it to database.
then redirect to the given website ( using the variable you've stored in step 3 ).
You can easily know the status ( 202 or any error) using any of server side scripting language.
If you are sending the user to another website, the only way to know that the user was successfully redirected is for that website to notify you in some manner. Once the user leaves your page (and that's what a redirect is - it tells the browser "leave this URI and go to this URI instead"), the scripts on that page stop running, so they can't collect any further information.
If you just need to know that the information was submitted successfully, your script could POST the data in the background, wait for a 200 response, then redirect after the information has been submitted. But that may not meet your requirements, since you still won't know if the redirect succeeded.
Another possibility which does allow you to know whether the page on the other site loaded correctly would be to open it in a new browser window/tab instead of redirecting. This is the only way to keep your page active (and, thus, your scripts able to run) while loading another page. However, it introduces other issues, like what to do with the original page. (Leave it open in the background (likely to confuse the user) or close itself after seeing that the new URI has loaded (could cause undesirable visual artifacts as one window/tab opens and then the original one closes; destroys browser history)?)
If at all possible, having the final destination site notify you when the transaction completes is almost certainly the best way to go.
To achieve point 3 you need to use cookies if you are actually trying to implement a login-cum-membersarea system. Othewise, you simple need a redirect inside a condition statement.
my $cgi = CGI->new;
if (condition) { print $cgi->redirect('https://www.examplesite.com/file.html') }
for a general way of doing point 1-2, you can look at the tutorial here:
http://practicalperl5.blogspot.com/
I've coded some custom navigation buttons into the project I'm working on, via javascript - they essentially copy the browser button functionality (brief wasn't initially clear on why separate buttons were required, but they asked for them):
function goBack() { window.history.back(); }
function goForward() { window.history.forward(); }
However, as the functionality is the same as the browser back button, the website asks if I want to resubmit POST data if I go back to a page with said POST data, which is undesirable. Ideally, to fit with the current site setup (all POSTs submit to the originating page, which checks for POST data and performs the relevant submissions to the database), I want to clear the POST data so there is no request to resubmit.
I'm not familiar with the Post/Redirect/Get (PRG) that people might recommend, and it doesn't seem to cover the concept of continually pressing "back"; if you submit a form, you post to a page which handles the post action, then redirects to a GET page - but the redirect is still in the history, meaning if you go back, surely you would hit the redirect page and just be sent "forward"? Plus, PRG seems mostly centred on page refreshing, which is not what I'm looking for at the moment.
The concept of PRG also seems to be due to the browser back button not allowing for additional code to control POST data, so coders have to make the best of what they can access.
With my relative freedom of having a custom back button which could allow for manipulation of POST/session/cookie data, I'd consider there should be some method of calling a global session variable or cookie on back button press, which then gets picked up on the previous page load to unset the POST data and the global session variable/cookie, but my attempts to implement something like this have not succeeded - they've been simple single-line setcookie('back', true) or set($_SESSION['back']=true) PHP snippets within goBack(), with PHP earlier in the page:
<?php if (isset([either set cookie or set session variable]) {
unset([either set cookie or set session variable]); // also tried changing 'true' to 'false' here
unset($_POST);
}?>
Is this kind of behaviour possible and I'm just looking at this from the wrong angle, or is the only way to do a successful back action while suppressing POST to re-engineer the site to use PRG, which will be comparatively significant legwork? Is there some other point in a page load/POST submit that would allow for clearing the POST data, to allow for the back button functionality I'm looking for?
EDIT
I, as an example, navigate to site.com/stuff/edit/[an ID], to edit an item of stuff. The first time I visit, there is no POST data, so the PHP check of isset($_POST) returns false and the page is simply rendered with a form which is populated by a GET.
I amend in the form and press submit. The submit sends the POST data to the target page; this is STILL site.com/stuff/edit/[an ID]! However, because there is now POST data, the PHP picks this up, validates it on the page (you'll see why later) and performs backend model and controller functions to update the item to the database serving the site.
Depending on whether the update was successful, the page then renders the form again, with the information which is retrieved from a GET, which pulls the information from the server (amended or otherwise) and either a success or fail message.
If I want to add a new item, I navigate to site.com/stuff/new; this navigates to the same page as site.com/stuff/edit, but PHP code determines the masking URL and renders different aspects of the code to look like a different page with a different POST action - it also notes there is no ID passed in.
I add an item, and the POST redirects back to the same page; this time, though, there is no Id from the server, meaning the code behind picks up the fact it is a new entry, and performs an insert. It then either displays a success message with a link to view/edit the new item, or a failure message with a prepopulated form to reduce retyping the new item into the form.
I hope this has helped show how this page works; its not necessarily how I would have written the site, but I've inherited the work from an ongoing situation and work with others who code in this way, so I need to be consistent or make unobtrusive changes rather than radical redesigns of in-use code.
I think this should do the job:
function goBack() {
var referrer = document.referrer;
if(referrer != '') {
window.location = referrer;
} else {
window.history.back();
}
}
I'm working on a website where the user fills out a form and submits it with a button that sends a POST. I would like the user to submit the POST and be redirected in the same action. Currently I have a javascript redirect (with window.location) implemented but I wish the page was condensed better. Is there an easy way for the same element to send a POST and subsequently send a GET to a different address? If it wasn't obvious I'm new to web development so apologies if my terminology is incorrect.
Just set the action attribute of the form to the URL you want to process the form.
You can't have a "submit to one URL and redirect to another" in one action.
Your options are:
Redirect to the second URL from the first one
Use AJAX to post the the first URL and in JavaScript redirect to the second
I have an HTML "Contact us" form which I plant on my client's HTML page,this form has an 'action' property with value that leads to my production system.
When my production system gets the form , it runs a vital code that arranges the type of request by type of request and perform some other QA at the code behind..
In case that the page has an error within our production system, we would like to notify the user that completed the form at our clients side that there was an error.
The problem is that when the form was sent we have no way to get back to the first form as a post was fired.
My question is , if there is any way to come back to the same page where the post was sent to the original page so we can notify the error AFTER the page was sent?
In other words, I need the form to be sent to the a address at the action property , and still make the browser stay at the same page.
Thanks.
You could embed a ReturnURL as part of the post data, that would identify where the post came from. Or perhaps embedding a customer code would be a better idea, that way you are not blindly redirecting to a URL (which could be hacked).
Is there a way (using javascript or other means) to suppress the form resubmission dialog that pops up when a page containing post data is refreshed?
This is a common problem and the solution has a name: PRG
The page that receives the POST handles it and then redirects the client/browser to another page which is retrieved with a GET request. So if the client refreshes, they are not re-POSTing the data.
The popup shows before the content is loaded. So any Javascript will be executed after you clicked one of the buttons on the popup.
What you can do on the server side is redirecting to another page (with no POST data) after completing all your actions with the data.