shopping cart - prevent same session ref being re-used after an order ?

[Dax_Trajero]

Whenever a user enters site and new session is created, along with a unique session ref (uuid).

Various housekeeping is performed when the session expires

BUT, how do I prevent a user who's just ordered, from returning to the site and re-using the same session ref ?

What's the best solution ? Can I prematurely expire the session, or perhaps start a new one and attach this user to it ?

[Owainnorth · Accepted solution]

Out of interest, why is it a problem if they *do*?

Seems a little odd to need to manually end a session, so maybe you're looking in the wrong place for a solution, tis all.

[Dax_Trajero]

Why ? I think I panicked when I read an article about a guy who assumed re-using the existing session would contaminate his session code.

I suppose if you perform the appropriate housekeeping once a user has ordered, then there's no reason to re-use the same session ref, assuming they wanted to order again straight away (perhaps they'd forgotten something)

Looking at my code, the orders table (and ordered_items table)  has no link at all to the shopping cart table, so it's not an issue.

Incidentally Owain, do you think it preferrable to use a RAM based shopping cart (opposed to table based) ? I think I want to make that my next project, choosing a suitable data structure to hold the cart in RAM.

[Owainnorth]

We force clients to log in or create an account at the point they first add something to their cart, which means all shopping cart data can be stored in the database indefinitely. It also means the site is easy scalable and can be load-balanced, which RAM-based storage rules out.

No-one has ever complained about having to log in, but many have been impressed to find things still in their cart when they come back to it.

As they navigate around the site and add things to their basket we add these into the tables - their Checkout view is then just selecting from the shopping cart table.

Once a user pays and clicks the complete button we tidy up the shopping cart tables and create an order. By the time the success page returns to their browser all their shopping cart data has been cleared, so there's no way they can do anything wrong or "re-send" the order if it's done properly.

Personally I wouldn't worry about it, concentrate more on making sure someone can't submit an order twice

[Dax_Trajero]

that's great info, thanks.

When a user submits the order, it takes them to our payment provider's website, where it clears their credit card (or not)

Do you mean, protect against them hitting the BACK button on the browser and re-submitting the order ?

What mechanism do you use to prevent that ?

[Owainnorth]

There's no one simple thing that needs doing, it's a multi-pronged (shudder) approach for want of a better sickening management phrase.

First up, when they click the Complete Order button, use Javascript to stop them clicking it agan. In the CF page that gets posted to, the *first* thing at the top of the page needs to be to check for the existance of a variable called  session.OrderSentForCompletion or similar, and make sure it's not true. If it *is*, they've gone back and re-submitted and the page should error or whatever you choose to do.

If it hasn't been set, do so, eg:  session.OrderSentForCompletion = true

Then send the request to the provider, get the data back and clear the session scope.

That way even if the CFM page is posted to twice, the first marks the flag to say it's been run, so the second won't then process it again. Apologies for the awful explanation but the girlfriend is watching "16 and Pregnant", and it's pretty distracting. Hopefully you get the rough idea anyway...

O.

[Dax_Trajero]

Yeah, totally get it, thanks.

Good tip about the table version of a shopping cart allowing you to leverage additional servers to cope with demand. If I had gone down the RAM based cart route, it wouldn't have done so.

Thanks again Owain

[Owainnorth]

No worries, if it saves someone else the pain we went through it's gotta be worthwhile

[BKBK]

Dax Trajero wrote:

... how do I prevent a user who's just ordered, from returning to the site and re-using the same session ref ?

Deny a returning paying(!) customer his session? Yours might be the only shop in town doing that.

If your session housekeeping is any good, then the session variables  pertaining to shopping-cart, payment and delivery would have been  cleared or re-initialized. Often, starting a new session means logging in again. There are a number of reasons why that can be undesirable.

I did an e-commerce course for a year, and learned some strange things. It is in fact to your advantage that a returning customer should keep his session, even after ordering.

For example, it is well known that the chances of a returning customer placing a new order is much higher when he is already logged in than when he has to log in afresh. You could test that hypothesis yourself. Psychologists have also found that e-shoppers often return to the shop to gloat at the goodies they've just ordered. You wouldn't want to deny them their gloating session, would you?

[Dax_Trajero]

Hi, thanks for the input.

If you check Owain's response, he's already said much of the same.

[BKBK]

Dax Trajero wrote:

If you check Owain's response, he's already said much of the same.

Please see the last paragraph as my input, not so much the technical stuff. In my experience, what I would call second-thought orders could contribute significantly to your sales.