On Mon, Jun 25, 2001 at 04:54:59PM -0700, Rob Bloodgood wrote:
> > > maybe storing 'last-access-time' on the server, instead of in
> > > the client-side, via cookie, would solve this snafu?
> >
> > But if you want to give out a new cookie on every request ?
> > How would you prevent them from copying or tampering with the contents?
> > a MD5-hash would stop them from changing values, but they could
> > still copy the cookie,
> > so the next idea is timeouts, and when you use timeouts it would
> > be nice if the user
> > don't have to login every couple of minutes, but would get a new
> > valid cookie automaticly...
>
> Aside from the fact that a server-side tracking system is bound to become
> incredibly unmanageable, very quickly, in terms of server-side storage...
>
> One of the methods I've used is to include a timestamp in the user's info
> (incl the MD5 hash? see the Eagle for Encryption of Cookies w/ MD5).
>
> THEN, when deparsing the cookie, DELETE it if the timestamp is too old.
>
> THEN, you either have a valid, non-timed out session, or no session at all
> (which is what you were worrying about in the first place, no?). If your
> system is based on session LENGTH (ie this ticket is good for one hour from
> last access), all you have to do is re-set the timestamp to the current
> time.
but he's saying that he can't send a cookie AND do the
'not-changed-since' thing.
me, on the other hand, i don't see the problem with
on incoming request
if has-cookie 'session'
{
update serverside 'accesstime' for session[this] to NOW
if not-modified-since
report same
else {
send headers w/ cookie
generate page
}
}
else
redirect to login page
doesn't look unmanageable to me (until someone shows me the
light, of course)...?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
