Professional Web Applications Themes

Help with setting expiration dates on COOKIES - ASP.NET General

This has to be a very common question, but my search did not come up with an answer. I needed to set an expiration time for a cookie. In .NET, is seems that the server-side code is used to set the expiration date of the cookie. More specifically, I've seen several examples (from the Microsoft site) where the cookie information, including the expiration date is set on the server. I wonder how this can work. If the client and server do not have the same time stamp, how can this work. For example, if the expiration time is 20 min ...

  1. #1

    Default Help with setting expiration dates on COOKIES

    This has to be a very common question, but my search did not come up with an
    answer.

    I needed to set an expiration time for a cookie. In .NET, is seems that the
    server-side code is used to set the expiration date of the cookie. More
    specifically, I've seen several examples (from the Microsoft site) where the
    cookie information, including the expiration date is set on the server. I
    wonder how this can work. If the client and server do not have the same time
    stamp, how can this work. For example, if the expiration time is 20 min and
    the client is 12 hours forward in time, as soon as the request returns to
    the client, the cookie is expired and no longer "issued".

    It seems to me that the server either needs to take into account, the
    client's time when the expiry time is set.

    I noticed that in some doentation, the expires flag is supposed to use
    GMT. But if the user plays with the date
    on their machine, the cookie may be prevented from expiring.

    What is wrong with my logic?


    Thanks
    Rick


    Rickey Tom Guest

  2. #2

    Default Re: Help with setting expiration dates on COOKIES

    Since the server is the one issuing the cookie and doing so on their 'clock'
    it logically makes sense that the expiration date specified is that of the
    server. In other words, the server has no knowledge of what time zone,
    date, etc. of the requesting client computer. Why should it? It's not
    necessary and having all the cookies issued timed/date stamped under one
    clock makes things a whole lot easier for the server to manage state.

    The server sends cookie information to the requesting source, the web
    browser. From there, expiration and removal of the cookie is the browser's
    responsibility. In creating the actual cookie (file) the browser may
    translate GMT to local time when creating the cookie.

    Hope this helps.
    --
    Peter O'Reilly


    Peter O'Reilly Guest

  3. #3

    Default Re: Help with setting expiration dates on COOKIES

    > Since the server is the one issuing the cookie and doing so on their
    'clock'
    > it logically makes sense that the expiration date specified is that of the
    > server.
    Thanks for your response.

    (Assuming that the client and server has the same time zone but for what
    ever reason, the clocks are out of sync.)

    Is this not the problem.
    I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10 min)
    The client machine has 9:00 PM July 27. So technically, this cookie has
    expired.
    As I understand from the description, the Browser will not issue the cookie
    any more since it is expired
    an it will not get persisted. This is what I observed in some software that
    I'm working with. The symptom is
    that the Login page keeps re-appearing. If I synchronize the time, then the
    problem goes away. However,
    on the internet, I have no control over client's time.

    Thanks
    Rick


    "Peter O'Reilly" <Peter_OReillytimeinc.com!N!O!.S!P!AM!> wrote in message
    news:utEsT8TVDHA.3232tk2msftngp13.phx.gbl...
    > Since the server is the one issuing the cookie and doing so on their
    'clock'
    > it logically makes sense that the expiration date specified is that of the
    > server. In other words, the server has no knowledge of what time zone,
    > date, etc. of the requesting client computer. Why should it? It's not
    > necessary and having all the cookies issued timed/date stamped under one
    > clock makes things a whole lot easier for the server to manage state.
    >
    > The server sends cookie information to the requesting source, the web
    > browser. From there, expiration and removal of the cookie is the
    browser's
    > responsibility. In creating the actual cookie (file) the browser may
    > translate GMT to local time when creating the cookie.
    >
    > Hope this helps.
    > --
    > Peter O'Reilly
    >
    >

    Rickey Tom Guest

  4. #4

    Default Re: Help with setting expiration dates on COOKIES

    > Since the server is the one issuing the cookie and doing so on their
    'clock'
    > it logically makes sense that the expiration date specified is that of the
    > server.
    Thanks for your response.

    (Assuming that the client and server has the same time zone but for what
    ever reason, the clocks are out of sync.)

    Is this not the problem.
    I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10 min)
    The client machine has 9:00 PM July 27. So technically, this cookie has
    expired.
    As I understand from the description, the Browser will not issue the cookie
    any more since it is expired
    an it will not get persisted. This is what I observed in some software that
    I'm working with. The symptom is
    that the Login page keeps re-appearing. If I synchronize the time, then the
    problem goes away. However,
    on the internet, I have no control over client's time.

    Thanks
    Rick


    "Peter O'Reilly" <Peter_OReillytimeinc.com!N!O!.S!P!AM!> wrote in message
    news:utEsT8TVDHA.3232tk2msftngp13.phx.gbl...
    > Since the server is the one issuing the cookie and doing so on their
    'clock'
    > it logically makes sense that the expiration date specified is that of the
    > server. In other words, the server has no knowledge of what time zone,
    > date, etc. of the requesting client computer. Why should it? It's not
    > necessary and having all the cookies issued timed/date stamped under one
    > clock makes things a whole lot easier for the server to manage state.
    >
    > The server sends cookie information to the requesting source, the web
    > browser. From there, expiration and removal of the cookie is the
    browser's
    > responsibility. In creating the actual cookie (file) the browser may
    > translate GMT to local time when creating the cookie.
    >
    > Hope this helps.
    > --
    > Peter O'Reilly
    >
    >

    Rickey Tom Guest

  5. #5

    Default Re: Help with setting expiration dates on COOKIES

    Any Comments?
    Thanks
    "Rickey Tom" <rickey_tomhotmail.com> wrote in message
    news:%239iSEHUVDHA.2104TK2MSFTNGP10.phx.gbl...
    > > Since the server is the one issuing the cookie and doing so on their
    > 'clock'
    > > it logically makes sense that the expiration date specified is that of
    the
    > > server.
    >
    > Thanks for your response.
    >
    > (Assuming that the client and server has the same time zone but for what
    > ever reason, the clocks are out of sync.)
    >
    > Is this not the problem.
    > I mean, the server specifies (logically) 3:00 PM July 27 (expiry for 10
    min)
    > The client machine has 9:00 PM July 27. So technically, this cookie has
    > expired.
    > As I understand from the description, the Browser will not issue the
    cookie
    > any more since it is expired
    > an it will not get persisted. This is what I observed in some software
    that
    > I'm working with. The symptom is
    > that the Login page keeps re-appearing. If I synchronize the time, then
    the
    > problem goes away. However,
    > on the internet, I have no control over client's time.
    >
    > Thanks
    > Rick
    >
    >
    > "Peter O'Reilly" <Peter_OReillytimeinc.com!N!O!.S!P!AM!> wrote in message
    > news:utEsT8TVDHA.3232tk2msftngp13.phx.gbl...
    > > Since the server is the one issuing the cookie and doing so on their
    > 'clock'
    > > it logically makes sense that the expiration date specified is that of
    the
    > > server. In other words, the server has no knowledge of what time zone,
    > > date, etc. of the requesting client computer. Why should it? It's not
    > > necessary and having all the cookies issued timed/date stamped under one
    > > clock makes things a whole lot easier for the server to manage state.
    > >
    > > The server sends cookie information to the requesting source, the web
    > > browser. From there, expiration and removal of the cookie is the
    > browser's
    > > responsibility. In creating the actual cookie (file) the browser may
    > > translate GMT to local time when creating the cookie.
    > >
    > > Hope this helps.
    > > --
    > > Peter O'Reilly
    > >
    > >
    >
    >

    Rickey Tom Guest

Similar Threads

  1. Setting cookies [URGENT]
    By Fnark in forum PHP Development
    Replies: 11
    Last Post: January 6th, 02:26 AM
  2. Setting cookies using WebDatablade.
    By Harry Johnson in forum Informix
    Replies: 13
    Last Post: November 13th, 09:26 AM
  3. Replies: 3
    Last Post: September 17th, 09:56 PM
  4. Help setting cookies without page reload.
    By Paul Kirby in forum PHP Development
    Replies: 3
    Last Post: July 21st, 02:48 PM
  5. password expiration
    By chris in forum Windows XP/2000/ME
    Replies: 7
    Last Post: July 19th, 04:49 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139