Howdy Ken!
I think there are two separate issues here -- there's an expiration
time on the cookie, which is your app's instruction to the client as
to how long the cookie should be kept. Then there's an expiration
time of the ticket represented by that cookie data (to use the
Ticket Auth example), which is the length of time the ticket is
valid for.
The ticket expiration time should be in a (tamper-proof) container
encoded within the cookie, and checked by the server side app for
freshness with each request.
Allowing a client's broken idea of the current time (whether broken
through maliciousness or through ignorance) to affect the duration
of the ticket's validity is (IMO) "a bad thing".
If the client's broken idea of the time causes the cookie not to be
stored for the correct duration, oh well, that's *their* problem,
right?
As Tom Christiansen likes to preach "Never trust anything sent from
the client".
<Steve>
On Tue, 1 May 2001, Ken Y. Clark wrote:
> On Mon, 30 Apr 2001, will trillich wrote:
> > after seeing the 'expires' dilemma brought about by poorly
> > configured client system clocks, what advice should we follow?
> > (what's the Official Party Line on expiring cookies?)
>
> I'm not really sure how to answer your question. I have usually
> understood that the client handles all of this. That is, you tell the
> client that the cookie is good for 30 minutes, and it figures out when
> those 30 minutes have expired and then quits sending a valid cookie back
> to the server. Is that right? Anyone? Anyone? Bueller?
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
