«

Hello,

I got the basic coding from perdoc on the usage of use CGI::Cookie. The main
examples show an expiry of '+3M' which they say means 3 months. I would
like my cookie to expire after 10 minutes. Does anyone know the equivalent
value? I cannot locate any other info in perdoc on this issue. Another
question I would like to ask is ... if a cookie is expired, will it still
return data if fetched? Can Perl read the cookie and determine its expiry
time and print that data to screen?



[Why I'm Asking]
I am trying to build a timeout subroutine for my program. When a user logs
in, a cookie is set for 10 minutes. Each primary subroutine of the program
will check the cookie to make sure its not expired and data is being
returned, if not, user is directed back to login page. I am doing this to
prevent bookmarking of the software once logged in. If the cookie had not
expired, it writes a new 10 minute cookie then shows the relevant dat for
that section/subroutine.


TIA!! Robert

"Robert TV" <> writes:
> I got the basic coding from perdoc on the usage of use CGI::Cookie. The main
> examples show an expiry of '+3M' which they say means 3 months. I would
> like my cookie to expire after 10 minutes. Does anyone know the equivalent
> value? I cannot locate any other info in perdoc on this issue.

I don't want to be too snarky, but in the *very same sentence* where
CGI::Cookie's docs explain that +3M means 3 months in the future, it
says: "-expires accepts any of the relative or absolute date formats
recognized by CGI.pm . . .". It also refers you to CGI.pm's documentation
in the very next sentence. I'm hard-pressed to see how you could have
missed this.

> Another question I would like to ask is ... if a cookie is expired,
> will it still return data if fetched? Can Perl read the cookie and
> determine its expiry time and print that data to screen?

This isn't a specifically Perl question; the answer would be the same
if you were coding in PHP or Ruby. That's not a slam, by the way;
partitioning a problem correctly is not always simple. Anyway, read
RFC2109 for the answer, or ask on comp.infosystems.www.authoring.cgi,
where it's at least on-topic for the group.

> I am trying to build a timeout subroutine for my program. When a user logs
> in, a cookie is set for 10 minutes. Each primary subroutine of the program
> will check the cookie to make sure its not expired and data is being
> returned, if not, user is directed back to login page. I am doing this to
> prevent bookmarking of the software once logged in.

Sorry, that's not going to help much. Cookie expiration times are
tracked on the client, not the server, and a malicious user-agent
could easily ignore the cookie's Max-Age setting. There are better
ways to go about this; I suggest you ask around in CIWAC, where that
sort of thing is more appropriate.

> If the cookie had not expired, it writes a new 10 minute cookie then
> shows the relevant dat for that section/subroutine.

I think you have a minor, but basic misunderstanding of how cookies
work. Asking around on a newsgroup where they discuss such things
would probably help clear things up.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

"Robert TV" <> wrote in message
news:Easxc.714573$Ig.256078@pd7tw2no...
> Hello,
>
> I got the basic coding from perdoc on the usage of use CGI::Cookie. The
main
> examples show an expiry of '+3M' which they say means 3 months. I would
> like my cookie to expire after 10 minutes. Does anyone know the equivalent
> value? I cannot locate any other info in perdoc on this issue.

Laziness usually isn't rewarded, since CGI::Cookie's documentation says:

-expires accepts any of the relative or absolute date formats recognized by
CGI.pm, for example ``+3M'' for three months in the future. See CGI.pm's
documentation for details.

Notice the last part of the explanation. If you'd gone to CGI.pm's
documentation, you would have inevitably found this:

+30s 30 seconds from now
+10m ten minutes from now
+1h one hour from now
-1d yesterday (i.e. "ASAP!")
now immediately
+3M in three months
+10y in ten years time
Thursday, 25-Apr-1999 00:40:33 GMT at the indicated time & date

Matt

Robert TV wrote:

> [Why I'm Asking]
> I am trying to build a timeout subroutine for my program. When a user logs
> in, a cookie is set for 10 minutes. Each primary subroutine of the program
> will check the cookie to make sure its not expired and data is being
> returned, if not, user is directed back to login page. I am doing this to
> prevent bookmarking of the software once logged in. If the cookie had not
> expired, it writes a new 10 minute cookie then shows the relevant dat for
> that section/subroutine.

Eeek. Bad way to do it - you're allowing the client to handle your timeouts, and
you really shouldn't trust your clients to do that.

Another way to do it would be to simply keep a connection id in the cookie, and
then store timeouts for connections in a DB table (which you control). Your
checking would go something like:

Get connection ID from cookie
-> go to login if none found
Get timeout for connection ID from DB
-> go to login if expired (delete from DB as well)
Update timeout for connection ID
Do whatever it is you wanted to do

You could also lock it down to source IP instead of a connection ID, but
problems arise here if the machine connecting is behind a NAT.

I'll leave other security concerns (such as guessing connection IDs - you may
want to consider some kind of authentication hash to accompany each connection
ID) up to you to research.

MB

"Matt Garrish" <> wrote:

> Laziness usually isn't rewarded, since CGI::Cookie's documentation says:
>
> -expires accepts any of the relative or absolute date formats recognized
by
> CGI.pm, for example ``+3M'' for three months in the future. See CGI.pm's
> documentation for details.
>
> Notice the last part of the explanation. If you'd gone to CGI.pm's
> documentation, you would have inevitably found this:
>
> +30s 30 seconds from now
> +10m ten minutes from now
> +1h one hour from now
> -1d yesterday (i.e. "ASAP!")
> now immediately
> +3M in three months
> +10y in ten years time

Laziness? I checked out the documentation at
http://www.perldoc.com/perl5.8.4/lib/CGI.html there is no reference to the
information you posted above. I only have access to www.perldoc.com for my
documentation. I also seached for cgi.pm, brought up the same page. There is
only a small section at the bottom called "HTTP COOKIES" and you info isn't
there.

R

"Robert TV" <> wrote in message
news:IAtxc.676945$Pk3.647491@pd7tw1no...
> "Matt Garrish" <> wrote:
>
> > Notice the last part of the explanation. If you'd gone to CGI.pm's
> > documentation, you would have inevitably found this:
> >
> > +30s 30 seconds from now
> > +10m ten minutes from now
> > +1h one hour from now
> > -1d yesterday (i.e. "ASAP!")
> > now immediately
> > +3M in three months
> > +10y in ten years time
>
> Laziness? I checked out the documentation at
> http://www.perldoc.com/perl5.8.4/lib/CGI.html there is no reference to the
> information you posted above. I only have access to www.perldoc.com for my
> documentation. I also seached for cgi.pm, brought up the same page. There
is
> only a small section at the bottom called "HTTP COOKIES" and you info
isn't
> there.
>

You're just making yourself look worse. Once again, if you'd bothered to
read the only section you're interested in you would have found this:

-expires The optional expiration date for this cookie. The format is as
described in the section on the header() method:

What do you find here (using the handy link you provided):

http://www.perldoc.com/perl5.8.4/lib...D-HTTP-HEADER-

I find the info I pasted above...

Matt

Robert TV <> wrote:

> I only have access to www.perldoc.com for my
> documentation.


Why is that?


If you have perl installed, you should have all its docs installed
right along with it.


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

Matt Garrish wrote:
> Laziness usually isn't rewarded,

That was uncalled for, Matt.

> Notice the last part of the explanation. If you'd gone to CGI.pm's
> documentation, you would have inevitably found this:
>
> +30s 30 seconds from now
> +10m ten minutes from now
> +1h one hour from now
> -1d yesterday (i.e. "ASAP!")
> now immediately
> +3M in three months
> +10y in ten years time
> Thursday, 25-Apr-1999 00:40:33 GMT at the indicated time & date

Not "inevitably", since you don't find it in the section "HTTP
COOKIES", as you could (would?) have expected, but you need to get
sight of the reference to the header() method in the description of
the -expires parameter.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

"Gunnar Hjalmarsson" <> wrote in message
news:...
> Matt Garrish wrote:
> > Laziness usually isn't rewarded,
>
> That was uncalled for, Matt.
>

I don't see why not.

> > Notice the last part of the explanation. If you'd gone to CGI.pm's
> > documentation, you would have inevitably found this:
> >
> > +30s 30 seconds from now
> > +10m ten minutes from now
> > +1h one hour from now
> > -1d yesterday (i.e. "ASAP!")
> > now immediately
> > +3M in three months
> > +10y in ten years time
> > Thursday, 25-Apr-1999 00:40:33 GMT at the indicated time & date
>
> Not "inevitably", since you don't find it in the section "HTTP
> COOKIES", as you could (would?) have expected, but you need to get
> sight of the reference to the header() method in the description of
> the -expires parameter.
>

Er, he was trying to find out how to *expire* the cookie, after all. I would
have expected the expires parameter to be the first place one would look.
You couldn't document the trail to the info more clearly (even starting from
the Cookies module), so I stand by my laziness comment...

Matt

Tad McClellan <> wrote:
> If you have perl installed, you should have all its docs installed
> right along with it.

I agree with "should". However, on Debian's GNU/Linux distribution you
have to install a separate documentation package.

Just FYI.
Chris