Cookie Expire Date question

[What-a-Tool]

How does the expire date work setting it server side with asp.
I know with javascript setting it client side it will be set to the clients
local time, and therefore expire when the clients local time reaches the set
expire-time.

But if it is an expire time set on my server in California, and the cookie
is put on a computer that is running on London Time, and the expire time is
set at the server as 20 minutes from now, the London computer will think
that the cookie has expired 7 hours and 40 minutes ago, right?

How does this actually work? Is it proper to just set my expire time as:

dtmExp = DateAdd("n", 20, Now())
Response.Cookies("MyCookie").Expires = dtmExp

Thanks

--

/ Sean the Mc /

"Opinions are like flatulence - everyone loves the sound of their own, but
anyone else's usually just stinks !"
-anonymous

[Kyle Peterson]

http://www.powerasp.com/content/code...ts/cookies.asp

"What-a-Tool" <Di*************************@IHateSpam.Com> wrote in message
news:MXPVd.48618$SF.7824@lakeread08...

How does the expire date work setting it server side with asp.
I know with javascript setting it client side it will be set to the
clients local time, and therefore expire when the clients local time
reaches the set expire-time.

But if it is an expire time set on my server in California, and the cookie
is put on a computer that is running on London Time, and the expire time
is set at the server as 20 minutes from now, the London computer will
think that the cookie has expired 7 hours and 40 minutes ago, right?

How does this actually work? Is it proper to just set my expire time as:

dtmExp = DateAdd("n", 20, Now())
Response.Cookies("MyCookie").Expires = dtmExp

Thanks

--

/ Sean the Mc /

"Opinions are like flatulence - everyone loves the sound of their own, but
anyone else's usually just stinks !"
-anonymous

[Mark J. McGinty]

"Kyle Peterson" <kp*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

http://www.powerasp.com/content/code...ts/cookies.asp

Sadly, that article doesn't address this question in the least way. See
*relevant* comments below...

[snip]
But if it is an expire time set on my server in California, and the
cookie is put on a computer that is running on London Time, and the
expire time is set at the server as 20 minutes from now, the London
computer will think that the cookie has expired 7 hours and 40 minutes
ago, right?
Indeed the expiry as sent by the server will effectively be the client local
time of expiry. We're struggling with this issue too, what we're looking at
is posting local client time to the server along with credentials, and
calculating an offset with which to adjust expiry times sent down from the
server.

The docs make some mention of setting expiry in UTC, but my observation has
been that premise is a big wad of hooey. Even when the server and client
are in the same time zone, we've seen problems occur when the client's
realtime clock is a few minutes fast. There is simply no getting around the
fact that expiry is enforced on the client end, based on that client's
clock.

The only way I can envision doing it correctly is for the server-side script
to be cognisant of the differential between client and server time-of-day,
and to adjust accordingly. But there are security ramifications, we don't
want a client to be able to set their date ahead by a week or a month [or
whatever] and thereby trick the server into sending a cookie that's good
further into the future than we allow.

-Mark
How does this actually work? Is it proper to just set my expire time as:

dtmExp = DateAdd("n", 20, Now())
Response.Cookies("MyCookie").Expires = dtmExp

Thanks

--

/ Sean the Mc /

"Opinions are like flatulence - everyone loves the sound of their own,
but anyone else's usually just stinks !"
-anonymous

[Evertjan.]

Mark J. McGinty wrote on 01 mei 2005 in
microsoft.public.inetserver.asp.general:

The only way I can envision doing it correctly is for the server-side
script to be cognisant of the differential between client and server
time-of-day, and to adjust accordingly. But there are security
ramifications, we don't want a client to be able to set their date
ahead by a week or a month [or whatever] and thereby trick the server
into sending a cookie that's good further into the future than we
allow.

What nonsense, if you send content to the client, even in the form of a
cookie, you have lost all rights to it[, that are not covered by law].

If you want a strict enforcement,
maintain the expiry on serverside in a database.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Mark J. McGinty]

"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn********************@194.109.133.29...

Mark J. McGinty wrote on 01 mei 2005 in
microsoft.public.inetserver.asp.general:

The only way I can envision doing it correctly is for the server-side
script to be cognisant of the differential between client and server
time-of-day, and to adjust accordingly. But there are security
ramifications, we don't want a client to be able to set their date
ahead by a week or a month [or whatever] and thereby trick the server
into sending a cookie that's good further into the future than we
allow.

What nonsense, if you send content to the client, even in the form of a
cookie, you have lost all rights to it[, that are not covered by law].

If you want a strict enforcement,
maintain the expiry on serverside in a database.

What in hell are you talking about? Expiry of all cached content, including
cookies, *is* enforced by the client, based on the client system time-of-day
clock. Cached items are stored on the client, correct? Once an item is
cached, in theory, it need never contact the server again, it can access
cached content until it expires in offline mode, do you follow?

For caching systems in general, expiry *must* be maintained by the system
that's managing the cache -- expiry can be set by the server, but it can
*only* be enforced by the client system.

We are not talking about "rights" to any content, we are talking about
cookies expiring early because the server resides in a different time zone.
If you have something *relevant* to add, by all means, we'd love to hear it.
If you don't understand, but would like to, that's fine too. But words like
"nonsense", particularly in combination with something off-the-wall that
doesn't pertain, are offensive... perhaps you'd care to choose them a little
more carefully?
-Mark

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Evertjan.]

Mark J. McGinty wrote on 01 mei 2005 in
microsoft.public.inetserver.asp.general:

"Evertjan." <ex**************@interxnl.net> wrote in message

Mark J. McGinty wrote on 01 mei 2005 in

The only way I can envision doing it correctly is for the
server-side script to be cognisant of the differential between
client and server time-of-day, and to adjust accordingly. But there
are security ramifications, we don't want a client to be able to set
their date ahead by a week or a month [or whatever] and thereby
trick the server into sending a cookie that's good further into the
future than we allow.
What nonsense, if you send content to the client, even in the form of
a cookie, you have lost all rights to it[, that are not covered by
law].

If you want a strict enforcement,
maintain the expiry on serverside in a database.

What in hell are you talking about?

Don't sweat, I will explain.
Expiry of all cached content,
including cookies, *is* enforced by the client, based on the client
system time-of-day clock.
If you say, as you did above: "sending a cookie that's good further into
the future than we allow.", the enforcement question is someting of "we",
the builder of the site, not of the client.

"Enforcement by the client" is a contradictio in terminis, when seen in
the light of clientside manipulation.
Cached items are stored on the client,
correct? Once an item is cached, in theory, it need never contact the
server again, it can access cached content until it expires in offline
mode, do you follow? For caching systems in general, expiry *must* be maintained by the
system that's managing the cache -- expiry can be set by the server,
but it can *only* be enforced by the client system.
Yes, so the question of you not "allowing" the user to manipulate what is
already on his pc memory is nonsense.
We are not talking about "rights" to any content,
Your word "allow" is all about rights.
we are talking about cookies expiring early because the server resides
in a different time zone.
That is understood. But also the expiry manipulation by the user was at
issue.

If the mechanism doesn't conform to your expectations, choose another
option. I suggested one.
If you have something *relevant* to add, by all means, we'd love
to hear it.
Who is "we"?
Usenet is not about getting only responses you love to hear.

I think my advice, that constraining allowance or disallowance of the
client/user should be done on the server, is very relevant.

Especially so as this ASP NG concerns itself mainly with serverside
coding issues, and clientside expiry problems are not really a serverside
code topic. But I am willing to ignore this relative off-topicnees of
your OQ.
If you don't understand, but would like to, that's fine
too. But words like "nonsense", particularly in combination with
something off-the-wall that doesn't pertain, are offensive... perhaps
you'd care to choose them a little more carefully?

Are we touchy today?

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Mark J. McGinty]

"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn********************@194.109.133.29...

Mark J. McGinty wrote on 01 mei 2005 in
microsoft.public.inetserver.asp.general:

"Evertjan." <ex**************@interxnl.net> wrote in message

Mark J. McGinty wrote on 01 mei 2005 in

The only way I can envision doing it correctly is for the
server-side script to be cognisant of the differential between
client and server time-of-day, and to adjust accordingly. But there
are security ramifications, we don't want a client to be able to set
their date ahead by a week or a month [or whatever] and thereby
trick the server into sending a cookie that's good further into the
future than we allow.
[snip]
Expiry of all cached content,
including cookies, *is* enforced by the client, based on the client
system time-of-day clock.

If you say, as you did above: "sending a cookie that's good further into
the future than we allow.", the enforcement question is someting of "we",
the builder of the site, not of the client.

No it is not, setting expiry is performed by the server, enforcing the
actual expiry of a cache object cannot possibly be performed by the server,
the cache object does not reside on the server. The only vestige of control
the server has is setting expiry, but the date and time of that expiry
setting will be evaluated by the client browser. When a cached object is
made to be unavailable, it is because code on the client system made it that
way.

"Enforcement by the client" is a contradictio in terminis, when seen in
the light of clientside manipulation.
Do you think that by "client" I'm referring to the human user of the web
app. I'm talking about the browser and o/s running on the client's PC.
That client browser must manipulate cache objects, that's its job, there is
no contradiction. You're getting lost in meaningless semantics.

Cached items are stored on the client,
correct? Once an item is cached, in theory, it need never contact the
server again, it can access cached content until it expires in offline
mode, do you follow?

For caching systems in general, expiry *must* be maintained by the
system that's managing the cache -- expiry can be set by the server,
but it can *only* be enforced by the client system.

Yes, so the question of you not "allowing" the user to manipulate what is
already on his pc memory is nonsense.

You've taken my comments out of context, and failed to grasp the
implications. The user is not freely allowed to manipulate browser cookies,
there are mechanisms in place to prevent conventional hand-editing. It's
surely possible, but I don't know how to hand-change expiry of a cookie in
my browser cache folder, do you? Even if so, that is not what I was talking
about, I didn't say anything about manipulating anything that was already
resident on the client. That is what you've misunderstood.

Let's break down what I said:

we don't want a client to be able to set their date ahead by a week or
a month [or whatever]
What this means is (in the context of calculating the offset between client
time-of-day and server time-of-day) that if the server-side script blindly
trusts the time-of-day as read from the client, it would be easily possible
for a user to advance his/her time-of-day clock, to affect the expiry
calculated and set by the server.
and thereby trick the server into sending a cookie that's good further
into the
future than we allow.

Operative phrase "trick the server."

If I set the date on my PC to this day in 2006, and the server blindly
calculates an offset based on it's TOD compared to mine, and it uses that
offset to adjust cookie expiry, what will happen? I'll tell you, the server
would set cookie expiry based on information it had received from the
client, and the cookie would last a whole year. That is not consistent with
our policy, which is to say that our policy does not "allow" it.

There are many things that are not "allowed" as a matter of policy, that are
fully within the control of those affected by that policy. Drivers are not
"allowed" to exceed the speed limit nor run red lights -- they frequently do
exactly that, but by law they are not "allowed" to. This usage is not a
contradiction and it is not nonsense.

Now, how does tracking anything in a server database address the problem
being discussed? As I mentioned, problems can occur even in the same time
zone. If the server sets expiry as 11:59PM on 01 May 2005, and my TOD clock
is 10 minutes fast, when midnight approaches I have a 10 minute gap during
which I cannot use the page, because the date, according to my CLIENT system
is a day later than that SET as expiry by the SERVER.

That's because expiry is enforced on the client system, and the date used
for that enforcement is the TOD as maintained by the client. You can toy
with words all you want, but what I've just stated is a simple fact.

We are not talking about "rights" to any content,

Your word "allow" is all about rights.

No it's about policy, but whatever... I've already addressed this above.

we are talking about cookies expiring early because the server resides
in a different time zone.

That is understood. But also the expiry manipulation by the user was at
issue.

Potential for expiry manipulation by falsifying input extracted by the
server -- which directly pertains to the prospect of acquiring the client's
system TOD and calculating an offset to adjust the expiry as set by the
server.

If you understood, why didn't you stick to the topic?
If the mechanism doesn't conform to your expectations, choose another
option. I suggested one.
It's a meaningless suggestion that does not address any aspect of the actual
problem.

And the mechanism fully conforms with my expectations, but that doesn't make
it highly functional.

If you have something *relevant* to add, by all means, we'd love
to hear it.

Who is "we"?
Usenet is not about getting only responses you love to hear.

I think my advice, that constraining allowance or disallowance of the
client/user should be done on the server, is very relevant.

Whatever...
Especially so as this ASP NG concerns itself mainly with serverside
coding issues, and clientside expiry problems are not really a serverside
code topic.
How the time of expiry as set by the server will be interpreted by the
client browser is hardly OT for an ASP newsgroup.

But I am willing to ignore this relative off-topicnees of
your OQ.
I didn't ask the OQ, I posted a reply, I quoted the OQ back in my reply...
what else could I have done so that it was more clear?

If you don't understand, but would like to, that's fine
too. But words like "nonsense", particularly in combination with
something off-the-wall that doesn't pertain, are offensive... perhaps
you'd care to choose them a little more carefully?

Are we touchy today?

We are now, arguing trivial semantics out of context, with people that say
they grasp the underlying concepts but repeatedly fail to demonstrate any
such grasp always gets me that way.

-Mark

Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Evertjan.]

Mark J. McGinty wrote on 02 mei 2005 in
microsoft.public.inetserver.asp.general:

Are we touchy today?

We are now, arguing trivial semantics out of context, with people that
say they grasp the underlying concepts but repeatedly fail to
demonstrate any such grasp always gets me that way.

Wel, you shouldn't.

Only the question is yours to put, the answers are not under your control.
By acting the way you do, you make a mockery of the possiblities of usenet.

If you don't like the responses on usenet,
there is a simple remedy:

== Don't ask the questions. ==

I will not go on with this tread.
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)