go back button causes problems

[omoutop]

Hello all and thanks for any advice/tips

I have been asked to upgrade an existing site (car rentals) and specificaly to block users from hitting the back button on their browsers.

Below is the main problem the company has:
- customer selects a car and a pickup loacation (area - officce). This is a pair of ids from database.
- after some other selections, the customer goes to checkout page
- the transaction has been assigned a unique id and if successful, sends a couple of emails to the company and to the customer.
The problem is that many customers hit the back button, going all the way to the begining of the proccess, select something different and procceed with the new rquest.
Since a unique id is already assigned to the customer, the new data overwrites the old ones.

Since an id is already registered to the customer, when he goes back to anearlier step, the script loads his selection but cannot prevent him from altering them.

My current thoughts so far:

Scenarion A - on a sucessfull transanction, i will copy the existing data to a different table, thus anything new afterwards, will get a new unique id.

Scenario B - assign a Y/N on successful transactions. But with this approach, i must edit/alter all scripts to ignore records with the 'Y' flag, and since this is not my code, i cant tell what bugs may appear or where.

Any other thoughts?

[Readie]

Rather than using $_SESSION or $_COOKIE variables, if you control everything via a MySQL database (including their progress number, i.e. step 3, step 4) then you can run a query every page load like:

$sql = 'SELECT step_number FROM customer_actions WHERE customer_id = "' . $some_variable . '" LIMIT 1';
$result = mysql_query($sql);
if(mysql_fetch_row($result)) {
// Continue happily
} else {
// Error
}

[rocknbil]

specificaly to block users from hitting the back button on their browsers.

This is really not the way to approach the problem. For one, it goes against accessibility/usability directives, for another, attempting to break the back button in all browsers is unreliable at best.

I do have a better one, and it shouldn't be all that difficult to implement, without trying to control user behavior.

The problem is that many customers hit the back button, going all the way to the begining of the proccess, select something different and procceed with the new rquest.
Since a unique id is already assigned to the customer, the new data overwrites the old ones.

Right. So here is what you do:

1. Add a field "completed" (or something) to your database, boolean or tinyint(1), defaults to false/0. On COMPLETION of the orders, update it to 1. Similar to your scenario B, if you add this as a new field and set the default as false or 0,, it won't affect any other codings for the transaction complete field. You'd just need to chase it down at final completion.

2. If it's not there already, move or set it up so this very first step in the process, or the very first time the id is inserted into the database, a new ID is generated every single time. Also at this point, be sure to unset any sessions or cookies that may be set so they are generated new:

if (isset($_SESSION['unique_id'])) { unset($_SESSION['unique_id']); }

3. Yes, this will create a lot of "dead records." The two easiest ways to manage it are a) cron or b) manual batch. Create a daily cron job to delete all records older than "today" with a completed status of 0:

delete from table where created <= date_sub(curdate(),interval 1 day) and completed=0;

I leave all records for "today" due to time differences, midnight, etc. If you like, you can keep them until they are two days old, if your user behavior tells you people leave their browsers open for days at a time (often happens on ecommerce sites.)

The second is to make that a manual update via any administrative area you have. The reason for using the second instead is it's good to look at "abandoned" orders or processes to get a feel for user behaviors.

Whatever you do, don't chase the back button disable, all paths lead to "not good". :-)

[omoutop]

Well after seeing both of your replies i will try the complete/not complete field approach and see how this goes.

I was also thinking of adding a field 'page_number' and check if saved data belong to current page or not and redirect to appropriate page (for example the first page of the application is step_1, step_2 and so on.
On the head of the page i check if my saved data set is equal or lower than the current page and if not, redirect user to proper page, ignoring any payment pages and email pages, all the way to the end of the proccess.

[TheMadScientist]

This is really not the way to approach the problem. For one, it goes against accessibility/usability directives, for another, attempting to break the back button in all browsers is unreliable at best.

And 3rd if you break the back button there's still a reload and refresh and delete the address in the address bar, and 4th do they really want all those calls about how their site is broken, and 5th if their customers want a different option or even just to go back one step to review something it seems like a completely stupid customer service idea to not allow them to do so, and 6th they're asking the completely wrong question, because rather than 'How do we keep someone from going back?' it should be: 'Why do so many people need to go back and start this process over, or redo something, or change something, or review something? What could we do different on the site to help people make the right selection or have the right information the 1st time?', and 7th ... End mini rant here.

It sounds like you were already convinced, but sometimes it can be a bit more difficult convincing the knot heads in the administration you're dealing with their answer is not the right answer and borders on stupidity, so I figured I'd help you and future readers be able to convince TPTB in situations like this how inane their proposed solution is.

Good luck with it...
I think you've got a couple good suggestions to work with.

[omoutop]

Mad, you are 100% correct.. but administration only cares and undertands so little and is not willing to invest time and money beyond a certain amount