Re: [PHP] Avoiding user refresh of pages with forms
- Original Message - From: Richard Lynch [EMAIL PROTECTED] To: John Wells [EMAIL PROTECTED] Cc: php-general@lists.php.net Sent: Friday, May 05, 2006 3:27 AM Subject: Re: [PHP] Avoiding user refresh of pages with forms On Thu, May 4, 2006 6:37 am, John Wells wrote: On 5/3/06, Satyam [EMAIL PROTECTED] wrote: I used that method initially, some months ago, but finally dropped it. It looked nice at first, but then I started getting into problems and required too many special cases to make it work. In the end, it wasn't a clean nor elegant solution. Satyam, Would you care to give some more details as to those edge cases that swayed you to drop the unique id approach? I've just recently added I'd be interested as well, as I've got an application that's been running for most of a decade that does this, with no complaints... [shrug] Maybe all the indie musicians using it are so web-savvy that none of them double-click on buttons, hit re-load, or use their back buttons and re-submit... Yeah. That's it. [that was sarcasm, in case you missed it :-)] -- Then, I had my version wrong from the start and because of that I never managed to get it right so, in the end, it is not worth it. I would have to dig into the CVS to pick it up but it is nothing to be proud of anyway, nothing to be learned from it except what not to do. Redirecting, though, works fine and never cared to look back. Satyam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
On 5/3/06, Satyam [EMAIL PROTECTED] wrote: I used that method initially, some months ago, but finally dropped it. It looked nice at first, but then I started getting into problems and required too many special cases to make it work. In the end, it wasn't a clean nor elegant solution. Satyam, Would you care to give some more details as to those edge cases that swayed you to drop the unique id approach? I've just recently added it to my forms (for those that I find need it), in addition to the redirect method you outlined below. Those two combined seem to really go the distance in creating a reliable exchange of data between client and server, as well as a better experience for the user (since the form is capable of handling a larger set of error cases). Also, with regards to sending success/failure messages across the redirection of your forms, I'd recommend considering sessions for passing the data. It keeps your URLs clean, and allows you to send complex data a bit easier (IMHO). For example if a user makes an error on a few different form elements, you can send back an array of messages to the user without having to serialize/unserialize in the ugly URL. -John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
Also, with regards to sending success/failure messages across the redirection of your forms, I'd recommend considering sessions for passing the data. It keeps your URLs clean, and allows you to send complex data a bit easier (IMHO). For example if a user makes an error on a few different form elements, you can send back an array of messages to the user without having to serialize/unserialize in the ugly URL. IE has a url length limit, so depending on how many steps you go through you might have issues with it not unserializing properly because the URL gets chopped off... -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
- Original Message - From: John Wells [EMAIL PROTECTED] On 5/3/06, Satyam [EMAIL PROTECTED] wrote: I used that method initially, some months ago, but finally dropped it. It looked nice at first, but then I started getting into problems and required too many special cases to make it work. In the end, it wasn't a clean nor elegant solution. Satyam, Would you care to give some more details as to those edge cases that swayed you to drop the unique id approach? I've just recently added it to my forms (for those that I find need it), in addition to the redirect method you outlined below. Those two combined seem to really go the distance in creating a reliable exchange of data between client and server, as well as a better experience for the user (since the form is capable of handling a larger set of error cases) Actually, I don't know if any of those 'fixes' actually did anything. I got some repeated log records (some of the operations were updates so they wouldn't harm the data, only update again what was already updated, but the log showed me both updates) and I can't really tell what was wrong and, in the end, those attempts at fixing them didn't work so they didn't fix anything. The redirection technique (which I learned about in this list) never failed me so in the end I dropped investigating any further, and I use that one alone. --- Also, with regards to sending success/failure messages across the redirection of your forms, I'd recommend considering sessions for passing the data. It keeps your URLs clean, and allows you to send complex data a bit easier (IMHO). For example if a user makes an error on a few different form elements, you can send back an array of messages to the user without having to serialize/unserialize in the ugly URL. --- It took a while for me to get used to accept to rely on session data and I'm still not completely comfortable with it. In a couple of places where the confirmation data would be too large to send in the URL, I would just send the primary key and re-read the data from the database, hopefully still cached and not requiring any actual disk access. As for the error messages, they don't go into the redirection which I only do on success. At first I did concatenate errors into a string, each enclosed in p tags and all shown in a div class=errormessage. In one app, and that is the style I will probably follow from now on, the error messages go into an array with the input field name as the key so each message can be shown right by the corresponding field. Actually a style I liked and will try in some real site is to put a simple and small error icon and have the text of the message in the 'alt' attribute so it shows when the cursor is over the icon. In that way, you can signal the place of the error without disrupting the layout of the form with a long text but you are not limited to show too brief a message. Most of the time, the user will realize what the error was anyway. (I'm talking about an intranet system with trained operators and somewhat dense forms). I fancy a floating div somewhere around but not covering the input field in error might also work, like a cartoon balloon dialog, but I'm not sure about it. Satyam -John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
On Thu, May 4, 2006 6:37 am, John Wells wrote: On 5/3/06, Satyam [EMAIL PROTECTED] wrote: I used that method initially, some months ago, but finally dropped it. It looked nice at first, but then I started getting into problems and required too many special cases to make it work. In the end, it wasn't a clean nor elegant solution. Satyam, Would you care to give some more details as to those edge cases that swayed you to drop the unique id approach? I've just recently added I'd be interested as well, as I've got an application that's been running for most of a decade that does this, with no complaints... [shrug] Maybe all the indie musicians using it are so web-savvy that none of them double-click on buttons, hit re-load, or use their back buttons and re-submit... Yeah. That's it. [that was sarcasm, in case you missed it :-)] -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Avoiding user refresh of pages with forms
Is there a way to prevent a re-posting of the form data when a user pushes the refresh button on the browser? I have a page that has a form to enter credit's or debit's to a user account. The top of the page displays the users account history and at the bottom is a form to add an adjustment. I just had a situation where a user came in complaining that the database is out of control every time I REFRESH the page the credit I put in gets added again and again!! He also claimed he was getting no warning message about that which was of course false, he just didn't read it. In any event, I need to make this more user proof. Thanks, Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
Is there a way to key off of the data inserted? Like some unique value or set of values that you can do a quick lookup before you insert/update/delete again... Or you could venture into an AJAX style of submission keyed off of a button click then a refresh to a 'report' page, in which case no POST variables are actually passed to the report page, so refreshing it will just present the same data... -Brad Jeff wrote: Is there a way to prevent a re-posting of the form data when a user pushes the refresh button on the browser? I have a page that has a form to enter credit's or debit's to a user account. The top of the page displays the users account history and at the bottom is a form to add an adjustment. I just had a situation where a user came in complaining that the database is out of control every time I REFRESH the page the credit I put in gets added again and again!! He also claimed he was getting no warning message about that which was of course false, he just didn't read it. In any event, I need to make this more user proof. Thanks, Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
Jeff wrote: Is there a way to prevent a re-posting of the form data when a user pushes the refresh button on the browser? I have a page that has a form to enter credit's or debit's to a user account. The top of the page displays the users account history and at the bottom is a form to add an adjustment. I just had a situation where a user came in complaining that the database is out of control every time I REFRESH the page the credit I put in gets added again and again!! He also claimed he was getting no warning message about that which was of course false, he just didn't read it. In any event, I need to make this more user proof. This question comes up a lot, and was covered fairly recently. The easiest way to do this is to have the script the form posts to simply redirect to a non-POSTed page once it's done its work. That way the user cannot re-submit the form without hitting the button again because that request never gets into the browsers history. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
Jeff wrote: Is there a way to prevent a re-posting of the form data when a user pushes the refresh button on the browser? I have a page that has a form to enter credit's or debit's to a user account. The top of the page displays the users account history and at the bottom is a form to add an adjustment. I just had a situation where a user came in complaining that the database is out of control every time I REFRESH the page the credit I put in gets added again and again!! He also claimed he was getting no warning message about that which was of course false, he just didn't read it. In any event, I need to make this more user proof. a a 'hash' token to the form - and when the form is submitted the first time log the token to the DB (or somewhere). each time a submission is made check that the token is not already stored - if it is don't let the submission through. you can double up that security by not only blacklisting (as above) but also whitelisting (the token has to be in your whitelist AND not in your blacklist before a submission is considered valid) Thanks, Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
something interesting to note:
header('location: newpage.php');
After processing your POST request, just send them to a new page and in
that page you can display the result of the process (It can require a
bit of change in your code) but the result will be that a refresh will
refresh the result page not the post page...
;)
PS: This doesn't prevent someone to hack your system and repost, but
someone refreshing or backing up a page should not land on the post
anymore.
Mathieu
Jochem Maas wrote:
Jeff wrote:
Is there a way to prevent a re-posting of the form data when a user
pushes the refresh button on the browser?
I have a page that has a form to enter credit's or debit's to a user
account. The top of the page displays the users account history and at
the bottom is a form to add an adjustment. I just had a situation where
a user came in complaining that the database is out of control every
time I REFRESH the page the credit I put in gets added again and
again!! He also claimed he was getting no warning message about that
which was of course false, he just didn't read it.
In any event, I need to make this more user proof.
a a 'hash' token to the form - and when the form is submitted the first
time log the token to the DB (or somewhere). each time a submission is
made check that the token is not already stored - if it is don't
let the submission through.
you can double up that security by not only blacklisting (as above) but
also whitelisting (the token has to be in your whitelist AND not in your
blacklist before a submission is considered valid)
Thanks,
Jeff
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
Brad Bonkoski wrote: Is there a way to key off of the data inserted? Like some unique value or set of values that you can do a quick lookup before you insert/update/delete again... Or you could venture into an AJAX style of submission keyed off of a button click then a refresh to a 'report' page, in which case no POST variables are actually passed to the report page, so refreshing it will just present the same data... -Brad Jeff wrote: Is there a way to prevent a re-posting of the form data when a user pushes the refresh button on the browser? snip To follow on from what Brad said - would it be possible to generate a key as a hidden value when the form is created. The first time the user submits the server checks if that unique code has ever been used within the current session - if not, adds value. If so, ignores. As a unique key you could use say timestamp plus random number. HTH Rory -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding user refresh of pages with forms
- Original Message -
From: Rory McKinley [EMAIL PROTECTED]
To: php-general@lists.php.net
Sent: Wednesday, May 03, 2006 8:32 PM
Subject: Re: [PHP] Avoiding user refresh of pages with forms
Brad Bonkoski wrote:
Is there a way to key off of the data inserted? Like some unique value
or set of values that you can do a quick lookup before you
insert/update/delete again...
Or you could venture into an AJAX style of submission keyed off of a
button click then a refresh to a 'report' page, in which case no POST
variables are actually passed to the report page, so refreshing it will
just present the same data...
-Brad
Jeff wrote:
Is there a way to prevent a re-posting of the form data when a user
pushes the refresh button on the browser?
snip
To follow on from what Brad said - would it be possible to generate a
key as a hidden value when the form is created. The first time the user
submits the server checks if that unique code has ever been used within
the current session - if not, adds value. If so, ignores.
As a unique key you could use say timestamp plus random number.
HTH
Rory
I used that method initially, some months ago, but finally dropped it. It
looked nice at first, but then I started getting into problems and required
too many special cases to make it work. In the end, it wasn't a clean nor
elegant solution.
Currently, my simple php files (that is, those not generated by frameworks)
have three sections, the form, the update SQL section and the confirmation
section.
To put it into pseudo-code, the thing goes like this:
if ($_REQUEST['submit'] == 'Ok') {
// validate data
// if there are any errors I concatenate the messages in a
$error_messages variable.
/ Do not output anything (error message or other status) until after the
redirect below
if (// no errors) {
// update, insert, delete or whatever you have to do
// if everything goes Ok, I do a redirect to this same page with a
new argument 'confirm'
// and whatever is needed to show a confirmation message
// Both the redirect() and build_url() functions are in my include,
I hope their purpose is obvious.
redirect(build_url('thispage.php',array('confirm' =
true,'otherdata' = 'values')));
}
}
if ($_REQUEST['confirm']) {
// here you show the confirmation message.
// if there had been any errors, it wouldn't come here, no need to check
that
// and refresh or back would fall here, not on the code above
}
// this is an option, if you want to show the form along the confirmation
message, don't put the else
else {
// here goes the form. The submit button name and value should match
the values of the first if
// if there were any error message, they should be shown here, either
before, after, or mixed withing the form fields
// if the form is shown along the confirmation, it might load the
previous values but then, be careful, duplicate records might be inserted.
}
Satyam
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
