in reply to cookie expire question

Since you're already set up with a server-side session, why bother with all the client side manipulation. Just "brand the browser" as I show in my must-read cookie article. Push one long-term cookie out to that browser. Note the browser's behavior via changing server-side state. When it gets time to put them into the login queue, you just redirect differently on the refresh. Too easy.

In fact, that's a nice idea for a column. I've added it to my list.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re: •Re: cookie expire question
by theorbtwo (Prior) on Mar 29, 2003 at 14:42 UTC

    BTW, writing-style note -- don't give references to years in things that should be long-lasting. Everything you said in that article still applies just as well (or better, with cell browsers, and the larger number of minor-player browers) to the world today... except for "that lasts until year 2003". I had to go check the date on the article, because it /is/ the year 2003. (I would have said 2037, or "for ten years", or somesuch, or "the year 2525, if man is still alive", if I felt like being cheezy.)

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]
      Yeah, that's been reported at least twice before. I sometimes write things that I strongly would need to reconsider later. {grin} (The famous "who would want to change these" hardwired constants in chat2.pl immediately come to mind...)

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]

In Section Seekers of Perl Wisdom