NYCPHP Meetup

[Tim Lieberman]

On Jun 21, 2008, at 2:07 PM, PaulCheung wrote:

> Hi
>
> Can anybody suggest a way around this problem or point me in the  
> right direction?
>
> I have a genuinely legitimate reason to disable the browser back  
> button, or at least the pages that have anything to do with the PHP  
> application I am working on.
>
> Here is the scenario
> A user likes the on-line service provided and decides to purchase  
> it using one of the standard on-line payment methods, typically  
> PayPal.
>
> Once payment has been made, confirmed and received, the user is  
> directed to an customer account creation page. Here the user enters  
> the usual standard account details such as Name, Address, Telephone  
> Number, User-Id, Password and so on.


Why do you make them wait to create their account until after they  
pay?  Aren't Name, Address, and phone necessary for payment  
processing anyway?

>
> The application then generates an access code, which is  
> automatically emailed from the application to the customer. As a  
> precaution all PHP sessions variables are cleared, the "customer  
> account creation page" is cleared and the user steered away from  
> the signup part of the application to Google's main navigation page  
> (this last bit being for testing purposes).

A precaution against what?

>
> Here in lays the problem. After initial creation of the account  
> code and when the back button is pressed a few times, the user  
> eventually return to the "customer account creation page". Which is  
> the step immediately following payment validation. At this point,  
> if the customer wants to create another new account all she or he  
> has to do is, fill it the form once more, press submit and another  
> new account is created. If the user just keeps doing this, he or  
> she just keeps on creating new accounts.

I assume you keep some record of the payment, that has some  
identifier.  Like maybe a primary key on some "payments" table in a  
database.  So why not associate accounts with payment_ids, and force  
accounts to have a unique payment id?  Adding that sort of simple  
rule to the account-creation process would solve things.  If someone  
backs up and tries to come through again, you don't create a second  
account, you just tell the user "Nice try, buddy..."

>
> I have tried to disable the browser back button; but am unable to.  
> I have researched JavaScript solutions and learnt, if the user  
> turns off JavaScript, that is that.

Of course.

You're trying to solve an authorization problem at the user interface  
level.  If something is supposed to be impossible, it's better to  
make the underlying model or business logic enforce the model.   
Trying to enforce it by tightly controlling stuff that happens in the  
user's browser is ineffective, because you don't control the user's  
browser.  But you do control what happens on the server.  And you can  
make sure the server only allows one account per payment in just a  
few lines of code.