|
|
Posted by Gordon Burditt on 04/23/07 23:47
>| >> data is in the db. a query will return the correct step that is next in
>the
>| >> ladder of steps to get to the top. user logs back in, that step is
>| >> displayed. now, pray-tell, HOW IS THE DATA LOST?
>| >>
>| >>
>| >
>| >And your mind is completely unable to grasp a simple concept. If the
>| >session is lost and there is no user login, there is no way to reference
>| >the row in the table related to this user.
>| >
>| >You have 500 users currently active. Suddenly one of them loses a
>| >session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
>| >USER? THERE IS NOT LOGIN!
>|
>| His solution to that is to display 500 credit card numbers and names
>| and addresses, mostly of other people, and let the user choose his.
>
>you can't make a good argument when you mix context scenarios. you know my
>architecture holds more merit than sessioning ESPECIALLY IN THIS CASE. first
>THERE WILL BE A LOGIN.
I've seen plenty of stores where no login is required to enter an
order. (but generally multiple screens are involved in entering
the order). Stores that absolutely require a login for physical
goods delivered by USPS, UPS, or FedEx seem to be pretty rare. If
you enter lots of orders, a login is convenient. If it's a one-shot,
maybe not.
Each order stands on its own. Either the site does not provide
order tracking, or it gives you an order number once the order is
finally submitted (and a site will typically suggest you print it)
which can be used later for tracking (and at that point, you can
call the order number a login if you like). Now, it's POSSIBLE for
a store to give an order number to an order at the time you start
composing it. I've never seen a store actually DO that, though.
>second, I CAN HIJACK SESSIONS. you wanna continue
Hijacking sessions is not all that easy without access to the user's
computer. Guessing valid credit card numbers is probably easier
(and is more profitable) than hijacking sessions. And sessions
often last for only a short period of time.
>arguing your case now?!!!
>| Even without privacy and security issues, it sounds a lot easier
>| to just start over, or better, go to a different web site run by a
>| different company entirely.
>
>you've lost credibility with me now, as you cannot state a case much less
>back it up.
I'm absolutely serious here: if you're going to show me 500
incomplete entries and ask me to pick mine, and I have to proofread
the one I select carefully to make sure it has no errors in it,
it's easier to enter it all over again. The amount of data entry
for an order of several items isn't that large, and it's much, much
easier than reading 500 incomplete entries to find mine.
My point here is: IF YOU LOSE THE KEY REFERENCING THE DATA, YOU
HAVE NO PRACTICAL WAY TO RECOVER. I don't care where you keep the
data referenced by the key. Put it in $_SESSION. Put it in a
database. Carve it in stone tablets if you like. The important
issue is what you use for a key. You can use a session key stored
as a cookie or as part of a URL, like PHP does. You can use something
fairly permanent you make the user remember (often called a "login").
You can use something temporary you make the user remember (like
giving the user an order number while the order is in process of
being entered). You cannot get away with making up something on
the fly when the user tries to come back to recover an abandoned
session.
Navigation:
[Reply to this message]
|