At 05:15 PM 1/31/2002 -0800, Jon Drukman wrote:
>At 09:03 PM 1/31/2002 -0400, Miles Thompson wrote:
>>If you want persistence then use a cookie to
>>- store the information
>>- to provide a key for fetching data from a database
>>or accept that if preservation of inter-invocation data is impt enough to 
>>require registration of users and a login if the client has cookies turned off.
>>
>>Sessions are supposed to be evanescent!
>>
>>(If someone else has responed, forgive me.)
>
>hmmm, i think i stated this badly.
>
>when a user logs in to my site, i load a bunch of stuff about them from a 
>database and put it in session variables.  right now i have the session 
>expiration time set to a pretty large value.
>
>they can come back later in the day and still have all their information 
>remembered, or they can hit the logout button to have their session destroyed.
>
>i see what you're saying about using a cookie, but the session IS a 
>cookie!  it just seems like it would be better to have just the one 
>cookie.  especially as the contents of a session cookie are hard to guess 
>at.  i'm not sure what sort of cookie i could give someone for persistent 
>login that isn't easily forged.
>
>-jsd-

Jon,

This I don't understand: "right now i have the session expiration time set 
to a pretty large value.".

I have believed, according to the docs, that when the user closed the 
browser the session was GONE. Or do you mean that the session is kept alive 
beyond the default period, so that they can leave the page open and come 
back a couple of hours later and they are still logged in, so to speak.

You're right about the idea of a cookie. I would guess a one-way encryption 
or hash of some combination of time, barometric pressure & info stored in 
the database which gets refreshed on each login, set to expire within a 
time that will work OK for most users. If they don't come back within that 
period they will have to log in again.

Somewhere over the past two weeks I saw an article which very neatly took 
apart most of our schemes for security and log ins. I guess if it really 
has to be secure, then you have users log in and change passwords frequently.

And of course, we have the problem of users who are concerned that cookies 
will eat their children so have them turned off. Shortly after a v. bad 
experience with Nimda, one client became hyper-excited about security and 
insisted that everything be  turned off: cookies, automatic downloads, 
script execution, etc. Of course most of his favourite sites didn't work, 
within two days he was back to "normal".


Miles


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to