[FX.php List] Problem with creating duplicate records

DC dan.cynosure at dbmscan.com
Fri Jul 21 18:11:58 MDT 2006


Though this is one 'intention' of GET v. POST remember the limits on  
GET requests are determined by the browser your users use. So, there  
are other practical implementation details that might cause you to  
simply use whichever is most expedient.

GET something like 227 characters
POST something like 33k

So, if you imagine sticking to this rule of thumb you might find  
yourself down the road with an advanced search page (which  
theoretically would be handled with GET) with lots of input fields  
and it just might choke on GET. IMO, because search interfaces use  
multiple form fields you don't really want to use GET.

Another reason not to use GET is that POST obscures the data from the  
casual snooper and makes your URLs look better. So, someone won't be  
tempted to click in the URL bar and see what happens if they change  
their id_number=234 to another number, etc...

GET requests are stamped into the webserver log so they are not good  
for sending passwords unless they are encrypted.

anyone else got any stumbling blocks to add?

dan

On Jul 21, 2006, at 7:01 PM, Steve Hannah wrote:

> This problem can be solved by carefully following the intentions of  
> HTTP requests:
> 1.  GET requests do not change data in the database.
> 2.  POST requests can update data in the database.
>
> Hence, your forms should always be displayed by a GET request, and  
> saved via a POST request.  When you process the form received from  
> a POST request, you do your database updates and then forward to a  
> new page with a GET request to show the next form.
>
> e.g.
>
> HTTP request: GET mypage.php :
>
> <form action="mypage_processor.php" method="POST">
> ... a bunch of fields in the form...
>
> </form>
>
> User submits this form which sends an HTTP POST request to  
> mypage_processor.php:
>
> In mypage_processor.php:
>
> if ( form validates ok){
>     process the form
>     if ( form processed ok){
>         forward user to next form or success page:
>         e.g.:  header('mypage2.php?message='.urlencode 
> ('Successfully saved content')); exit;
>     } else {
>         forward user to failure page.
>         e.g.:  header('my_failure_page1.php?message='.urlencode 
> ('Failed because ...')); exit;
>     }
> } else {
>     form didn't validate -- either display the form again right  
> here with info about which fields were
>    input incorrectly -- or forward back to the original form for  
> the user to fill in... probably easier to
>    just display it here again:
>
>    include('mypage.php');
>
> }
>
> This way, if the user reloads a form, it just reloads the form -  
> and doesn't trigger the processing information.
>
> Hope this helps.
>
> ----------------------------------------
> Steve Hannah
> Web Services Developer
>
> Faculty of Applied Sciences
> Simon Fraser University
> shannah at sfu.ca
> 604-268-7228
> Homepage: http://www.sjhannah.com
> --
> Need to build a database driven web application quickly?
> Try Dataface: http://fas.sfu.ca/dataface
>
>
>
> On 21-Jul-06, at 2:45 PM, Jerry Do wrote:
>
>> Hello all,
>>
>> I am new to fx.php and php.  I have problem users create duplicate  
>> records
>> by reload the response page.
>> For example:
>> I have a form name "formA" and the ACTION ="formA_response.php".
>> When the user click submit, the form will send all the information to
>> formA_response.php.
>> The formA_response.php page is the page to create new record.  I  
>> noticed
>> that if a user reload formA_reload.php,  new record will be  
>> created.  Is
>> there a good method to prevent the user reload the page or going  
>> to that
>> page?
>> I am thinking that I might send to a page that will create the  
>> record then
>> close that page after the record created.  However, I am not sure  
>> it will
>> work or how to do write it yet.
>>
>> Any input is welcome.
>>
>> Thank you in advance,
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list



More information about the FX.php_List mailing list