Posted by Steve on 04/24/07 04:28

"Gordon Burditt" <gordonb.60guj@burditt.org> wrote in message
news:132qhdai5fgbjfd@corp.supernews.com...
|>| >> 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.

well, on a smaller scale, pizza stores most often give 'order numbers' at
the beggining of an order. yes, i've worked as a contractor for a pizza
company (dominos - helped develop their stores' pos...it's called pulse in
case you don't believe me...that began in early 2000).

what we're talking about here is theory. the op didn't put any requirements
on his context. i made several points to counter stucco - he has a thing for
me you know. jerry just said that there was no advantage to db storage as
compared to sessioning data. this is clearly false and i gave examples of
where it was superior...and at worst, only == sessioning data. with no
unique id, db storage is equal to sessioning but clearly not what jerry
wants to concede.

it's interesting to me that the op asked how he could get sessions to not
drop. i gave suggestions directly to that and mentioned db storage as a
fail-safe. all jerry can do is bash that suggestion (not very well though),
and still hasn't answered the op's direct problem.

so why are you jumping into this fray?

anyway,
| >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.

depends on server's config now don't it. give me the ability to upload files
to a site, and i'll echo out every session id there is on the server. if you
think hijacking a session is difficult, you need to school yourself a bit
more. the moral of that story is to only session the essentials...like a
user name and password and some kind of security code that is only valid in
a limited context. all three give you better security as all can be checked,
data is isolated to a secured/seperate location, and all can be recalled on
demand. each of these layers of seperation are what give better
security...not just thinking that it is easier to do x or y instead of what
i said...hijack your sessions. if i knew that's where you stored your
financials, fuck yeah...that's the first place i'd go. and, i'd get there
to.

| >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.

you painted that picture, not me. i don't claim that's the best solution
either. what i am saying is that that's the worst case scenario you can
paint, and it still only makes db storage == to sessioning data. the
security issues, scalability, data sharing, and fail-safe mechanisms just
aren't going to show data for sessioning data. that was my point to jerry.
that he cannot say sessioning data and db storage are ==. they only can be
in select instances.

| 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.

nor did i disagree with you. nor did i ever state anything to the contrary.
i said you're not always shit out of luck if you use db storage. if you
session your input, you are sol even IF you enable logins or ANY unique id.
if the session is lost, the data is ALWAYS gone. however with a unique id
and db storage, you just pick up where you left off.

architectually (and theoretically), what would it take to scale sessioning
data if someone over the project said, 'we need to secure this site more
thouroughly. let's say after x minutes of inactivity, we log a user out'? a
common practice during a logout is to erase a session's data and call
session destroy. what happened to your user's work? are you going to try and
store the data somewhere for that user? or, is he sol because of the new
policy. i happen to think the policy shouldn't cause a loss of work.

now, what impact would that have on a db stored architecture? what would you
have to do differently here? nothing...save, the user has to log back in
again and pick up where he left off.

why is this hard to see?

[Back to original message]