|
|
Posted by d on 09/26/71 11:37
"G.E.M.P" <slowtorture@spammers.com> wrote in message
news:gZidnYgTJrA_qVPeRVn-pw@bresnan.com...
>
--------------------------------------------------------------------------------
> High Level Session Handling Design for a Shopping cart
> 0) What am I missing?
> 1) How does OSCommerce do it?
Take notes from OSCommerce, but for the love of God don't use it ;)
OSCommerce stores a composite ID of the product and it's attributes (say
colour=blue, size=large) in the DB alongside the user's ID. That's
essentially it.
> I'm thinking about building a shopping cart from scratch,
> using a library of dynamic screen generation routines
> (already written) that take an XML stream as input from
> various "search for products" forms. That way I can
> run queries in one window and display the dynamic
> results in another. The searching functions will probably
> not index into a relational schema. Instead I'll use
> Lucene to parse keywords and values out of XML-based product
> descriptions. I know a lot about XML, Lucene, Xpath, XQuery
> and dynamic screen rendering. But I have no experience
> (at all) working with shopping carts in general.
Shopping carts are scary to many developers, as it's usually a break from
the norm. They are, however, a great demonstration of where a small amount
of code, properly organised (as I'm sure yours will be), can provide a lot
of very useful functionality. It's just storing numbers next to each other.
The "cart" is simply a relationship between the user and a product, after
all.
> 2) How does repeat customer session handling usually work?
> When a customer first logs in we generate a sessionID
> and send it back to the client as a cookie.
Bingo.
> Later on in the session, and before we can consumate a purchase,
> they have to supply name address and (https) credit card number. We
> put that stuff (not including the credit card number), along with the
> sessionID, into a database of some kind. That part (customer contact info)
> may well be mysql.
That's essentially it. When the user logs in, the session is
created/resumed. You can then add to that as and when you need to. When a
purchase is going to be made, you ask them for their details, etc (and
username/password), and set them up a user account. You can then create a
login script to populate the session with their stored data when they log
back in (say, cart contents).
> Any current shopping cart items are handled as
> session memory items. Session memory will probably track items
> with a hashed array of productObject types, which is a complex
> object class that includes lots of generic stuff about each product
> in the catalog (name, inventoryID, etc)
> That way we can jump from screen
> to screen without losing session, while finishing up at a "review cart"
> screen.
You just need to hold the composite IDs of the products, and their basic
display information (price, actual price, make, model, etc.).
> Review cart has cart-editing features (two of these, none of those)
> plus contact information editing, plus a "Make Purchase" button that sends
> the transaction
> off to a 3rd party transaction handler, sends an email receipt
> to the customer and then prints a Thank You screen. It's probably a good
> idea NOT to store
> credit card numbers on the server. Instead we hold it just
> long enough to clear the transaction.
You can hold it on the server - just do it sensibly. Obviously you should
get rid of it when you've used it, as you say.
> 3) What security pitfalls surround holding credit card information
> in session memory? How long do we keep credit card numbers?
Don't keep it in session memory, unless you can guarantee that the path
where the sessions are being stored (assuming you're using the default
file-based sessions) is secure, and impossible for non-web-server users to
gain access to. You could write a custom session handler (really quite
easy) which incorporates some more advanced security features to assure the
security of the credit card information. Once you have their money, get rid
of the credit card information. That's law in many countries, so it's
better to be safe than in court ;)
> 5) If the customer negotiates his/her way all the way out to
> the cart editing screen, where they do fill in a card number, name
> and address, and then change their mind, and go back to
> the shoppingMode screens, do we NULL out the credit card in
> session memory? Or keep it around. And if so for how long?
Personally, I'd give the user the choice. You can have the credit card
information time out in the session, so if they don't go back to the
checkout in, say, 5 minutes, then your code will nullify the number in the
session.
>
>
>
I wish more people wrote their own shopping cart/store systems, as opposed
to just relying on OSCommerce and its derrivations (zen cart, I'm looking at
you). Those products simply suck, and if talented folks make their own,
their grip of mediocrity will be broken. Good luck!
Navigation:
[Reply to this message]
|