Cookie Expire Date question

Discussion in 'ASP General' started by What-a-Tool, Mar 4, 2005.

  1. What-a-Tool

    What-a-Tool Guest

    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
     
    What-a-Tool, Mar 4, 2005
    #1
    1. Advertising

  2. http://www.powerasp.com/content/code-snippets/cookies.asp

    "What-a-Tool" <Die!FrigginSpammers!DieDie!@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
    >
    >
    >
     
    Kyle Peterson, Apr 30, 2005
    #2
    1. Advertising

  3. "Kyle Peterson" <> wrote in message
    news:%...
    > http://www.powerasp.com/content/code-snippets/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
    >>
    >>
    >>

    >
    >
     
    Mark J. McGinty, May 1, 2005
    #3
  4. What-a-Tool

    Evertjan. Guest

    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)
     
    Evertjan., May 1, 2005
    #4
  5. "Evertjan." <> wrote in message
    news:Xns9649C48E34C3Feejj99@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)
    >
     
    Mark J. McGinty, May 1, 2005
    #5
  6. What-a-Tool

    Evertjan. Guest

    Mark J. McGinty wrote on 01 mei 2005 in
    microsoft.public.inetserver.asp.general:
    > "Evertjan." <> 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)
     
    Evertjan., May 1, 2005
    #6
  7. "Evertjan." <> wrote in message
    news:Xns9649EB224BAB6eejj99@194.109.133.29...
    > Mark J. McGinty wrote on 01 mei 2005 in
    > microsoft.public.inetserver.asp.general:
    >> "Evertjan." <> 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)
    >
     
    Mark J. McGinty, May 2, 2005
    #7
  8. What-a-Tool

    Evertjan. Guest

    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)
     
    Evertjan., May 2, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joey Powell

    Forms Authentication Cookie Does Not Expire

    Joey Powell, Dec 2, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    504
  2. Big E

    Cookie Expire

    Big E, Aug 30, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    1,058
    Scott M.
    Aug 31, 2004
  3. Peter Grison

    Date, date date date....

    Peter Grison, May 28, 2004, in forum: Java
    Replies:
    10
    Views:
    3,302
    Michael Borgwardt
    May 30, 2004
  4. Tongass Park Neighborhood Association, Juneau Alas

    Cookies expire immediately, not when set to expire

    Tongass Park Neighborhood Association, Juneau Alas, Oct 1, 2009, in forum: ASP General
    Replies:
    2
    Views:
    1,227
    SQLDude
    Nov 24, 2009
  5. paul
    Replies:
    32
    Views:
    402
    Thomas 'PointedEars' Lahn
    May 11, 2006
Loading...

Share This Page