Evertjan. said:
Mark J. McGinty wrote on 01 mei 2005 in
microsoft.public.inetserver.asp.general:
Evertjan. said:
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.
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.
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.
Your word "allow" is all about rights.
No it's about policy, but whatever... I've already addressed this above.
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.
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?
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