I'm writing a PHP app which presents people with a form to fill out and submit.
Once the user submits the form, things change in the database and the form should become inaccessible to the user.
If, however, the user presses the back button after submitting the form, they can see it again. I have code in the back end to prevent a user from being able to re-submit an already submitted form, however ideally if the user presses the back button, they will get the same message as if they were to just navigate to it outright: A message is shown on the screen saying that this form has already been submitted and is now unavailable.
Aside from an AJAX call to the back-end to check if the form has already been submitted, and redirect the user to the "form submitted and now unavailable" message, is there any other (better?) way of handling this?
Since this will only be used internally on a SOE, I only need it to work on IE8+.
You can consider adding this information to session/cookie. Alternatively if you have authentication system, you can store this information in the database.
Probably the first option is easier and sufficient.
so basically before displaying the form you check if the cookie alreadySubmitted is 1. If yes - error message, otherwise - form. When you submit the form, just set this cookie to alreadySubmitted.
However be aware, that if someone deletes cookie, he will be able to trick your system.
Related
My site uses a combo of sessions and get/post.
When user hits back button, it says "confirm you want to resubmit form" or a similar message, depending on the browser. Then the user has to also refresh the page.
How can I make it automatically resubmit form. I don't want users seeing this message and getting stuck when they hit back.
I have PHP + HTML
you can use get method in post method resubmit message is appear and if you want to use post method then on server page use header such as header('location:index.php') and change index page that you want.
Not answering your question, but do reconsider.
POST actions should change the state of the server. GET actions should be transparent. If you're using a POST to submit data to commit to a database or launch nuclear missiles or whatever, the resubmit warning exists for a reason: imagine your embarrassment when you launch two nuclear missiles, but was only trying to launch one.
GET actions, on the other hand, by their specification, should never meaningfully impact the world, so the resubmission is safe. If there is something the user is allowed to go back to, it's a GET page. A POST page should not be returnable-to using the back button (or rather, the user should be made aware of it).
If you have to suppress this warning, you are doing something wrong.
I have html page where you can insert some information and then submit this form, which will change information in database. I do it normally, that submit button call php file in server.
But what I want, is that this php file will return to me the same html page of which I sent request, with modified changes. e.g: there will be "Database update successfully" text added etc.
How can I do it without AJAX ?
Thanks
In the PHP file, do a call to the header() function to redirect the user. For example:
header('Location: url.php');
To change the content of that page they are redirected to, you could pass something in the URL that your page will check for. For example:
header('Location: url.php?submitted=1');
There are other ways to implement this, but this seems the most straightforward to me. Note that you don't want to call header() until the end of your submission page.
Use POST/REDIRECT/GET
Excerpt:
The user submits the form
This is pretty straight forward. The user completes the form and submits it by pressing the submit button or enter on their keyboard.
We store the form data in a session
After processing the data we discover an error so we need to redisplay the form with an error message but we also want to populate
it with their data so they don't have to refill the entire form just
to fix potentially one little mistake. So we store their data in a
session ($_SESSION). Session variables carry over from page-to-page
for as long as the session is valid or until they are deleted. This is
an ideal place to put their information since redirecting will cause
their information to be immediately discarded by the server.
We redirect the user back to the same page using a 303 redirect
Once we have saved the user's information in their session we need to redirect them back to the same page. In order for this to work
properly we need to use a 303 redirect. This means we need to send a
303 header with our redirect. A 303 redirect will cause the browser to
reload the page without the initial HTTP POST request to be
resubmitted. This includes when the user uses the back or refresh
buttons.
We re-populate the form using the data stored in the session
When the page is sent to the user we re-populate it with their information we saved in their session.
Only by generating the whole page in CGI first, unless you go through some horribly convoluted method of getting value of one of the fields to be set to document.innerHTML or something like that in Javascript. But you'll go through hell to get the quoting issues resolved. Use AJAX, it was created for precisely this purpose and exactly to avoid the utter hell associated with what you need.
Alternatively: the "modified piece" of the page may be an iframe, and you can set the target attribute of the form, so that the PHP returns only the iframe content.
I'm simply trying to figure out the correct way to lay out the architecture for my forms to meet the following requirements:
The form must have server side validation.
If a user is filling out a form on domain.com/register and the form doesn't pass server side validation, they should be brought back to domain.com/register with the errors displaying.
(continued from point #2) If the user is brought back to domain.com/register to fix validation errors, the data they have already entered in to the inputs should automatically display.
If a user clicks back or forward on the form page the browser should not throw the "Confirm Form Resubmission" warning.
I'm a bit confused on where the form submit should be posting to. Should the form on domain.com/register post to a different page that simply handles the validation? If so, how do I pass the validation errors and inputed data back to domain.com/register?
Or, should the form be posting to itself? If so, how do I prevent the browser from throwing the "Confirm Form Resubmission" warning when clicking the back or forward button?
A logical way of approaching this (that attempts to keep all related items as localised as possible), would be to use a single page that has a "mode" switch statement near the top with an "update" case in it that contains your validation code.
Within the form, you'd simply post to the same page that you're on, but you'd add a hidden field in the form called "mode" with a value of "update". As such when the form is submitted execution will flow into the "update" case of your switch statement and you can carry out the required validation.
If the validation succeeds, you'd usually kick forward to another page (via the use of header('Location: ...'); followed by exit();) and if validation fails, execution will simply continue down the page at which point you should output the errors that occurred during the validation.
I am currently working on a zend framework site using an ACL.
The ACL works and uses a DB for storing privaliges. What I have done so far is, on in a preDispatch I capture where the user wanted to go to, and if they need to login to get there the page displays the login form. I have also captured if a user has submitted a form and stored the data (location and form data). No problems so far.
The user submits the login form, and I then check if I have a location to send them onto, again no problems here, this works.
However I want to be able to submit the original form data now they are autherised - the only problem is, if I redirect them to the page, the call to:
$this->getRequest()->isPost()
fails as it isn't a post request.
I can forward the user to the page on sucessful login, and in the preDispatch set $_POST to the data originally captured, this works as the original POST still stands, this works but I do not think is the correct way to do this - specially the URL - obviously the page displayed is correct, the form has been submitted correctly, but the URL is of the login process.
Obviously I could change from using $this->getRequest()->isPost() but as there are large amounts which would need changing I was hoping not to have to do this.
The way it's done usually (seen this on many sites), would be to store the form data and requested action in session, then redirect the user to a login page. When login is authorized, you read the session for any pending action, reload the form and populate it with data from session (properly clearing any pending action from session afterwards). The user would just have to click Submit again.
The other way to do this would be to use HttpClient and submit the data as POST with it.
I want to ask a best practice question.
Suppose I have a form in php with 3 fields say name, email and comment.
I submit the form via POST. In PHP I try and insert the date into the database.
Suppose the insertion fails.
I should now show the user an error and display the form filled in with the data he previously inserted so he can correct his error. Showing the form in it's initial state won't do.
So I display the form and the 3 fields are now filled in from PHP with echo or such. Now if I click refresh I get a message saying "Are you sure you want to resend information?".
OK.
Suppose after I insert the data I don't carry on but I redirect to the same page but with the necessary parameters in the query string. This makes the message go away but I have to carry 3 parameters in the query string.
So my question is:
How is it better to do this? I want to not carry around lots of parameters in the query string but also not get that error. How can this be done? Should I use cookies to store the form information.
Your first scenario seems the most valid.
i.e.
User submits the form
Some problem prevents submission, so form is re-displayed
If user "refreshes" they see the usual message about re-sending information (although their most likely path of progression is to re-submit the form that you are kindly re-populating for them).
The "Are you sure you want to resend information?" message is perfectly valid in the event of someone refreshing the page after a form submission, so don't write code to specifically break this behaviour.
I think generally people would temporarily store the submitted data in a session variable, and send the data back to the client.
Maybe it is besides the point but you mentioned "wrong dates", and I think many would say you should arrange things so that the user cannot unintentionally send you wrong dates.