In there, I say something like: do not use the presence of a cookie to indicate a logged-in state, because the browser is free to ignore your requests to remove the cookie or expire it after a while.

Instead, simply ignore that particular cookie if it's sent in the future. This means you should use a cookie only as a key to a server-side database which shows the current state of logged-in or not.

-- Randal L. Schwartz, Perl hacker

Hi Merlyn,
maybe I am wrong but I thing that there is litle mistake in your code. Line 34:

my $cache = File::Cache->;new({namespace => 'cookiemaker',
[download]

Should be without ";":

my $cache = File::Cache->new({namespace => 'cookiemaker',
[download]

This probabably happened by copying line 33.

Your servant Li Tin O've Weedle
mad Tsort's philosopher

That's an artifact (read: "bug") from pod2html, which is why I also provide the companion colNN.listing.txt file in the same directory.

-- Randal L. Schwartz, Perl hacker

Thanks merlyn - shortly after posting this, I broke out the latest "Web Techbniques" and re-read your article a couple times. Your right - as I was testing new ideas, I noticed that sometimes my browser did in fact ignore the cookie expiry all together. Therefore, I am going to need to implement some type of server side session info, has had been previously suggested.

Thanks for all the help!

r. j o s e p h
"Violence is a last resort of the incompetent" - Salvor Hardin, Foundation by Issac Asimov

Merlyn was right again,
but should be interesting to know which one browser has problems..... Microsoft Internet Exploder? Netsuck?
I am using MSIE 5.0 (PC) and I founded some diferencies between PC and Mac version - right with cookie and redirect operations.

THX

Li Tin O've Weedle
mad Tsort's philosopher

as you can see, the cookie is the same...

Perhaps the problem is that $in{usr} and $usr don't match?

The solution is to recode your CGI to display a "you are logged out" message (which is good form anyway) instead of a redirect. Then you CAN pass the cookie, and all will be right with the world.

Gary Blackburn
Trained Killer

Trimbach, you may be half right. But it is possible to accomplish this without a two-step process.

First, the browser can indeed handle the cookie header and the "Location: ..." header line in the same server response. The Location line must come last and it must end with two new-lines.

But I can find no indication in my quick re-visiting of the docs that the CGI redirect function allows the specification of a cookie along with the redirect. (Update: but see the following response by athomason.) And the CGI pod says don't print a header along with a redirect.

So I accomplish this manually:

  print "Set-Cookie: $usr=x;expires=-1d\n";
  print "Location: http://mypage.com/my_login.html\n\n";
[download]

There may be a gotcha here but I haven't run into it.

BTW, are you sure that $in{usr} and $usr have the same value? That would, of course, be crucial to what you are trying to do.

As dvergin points out, browsers are perfectly capable of handling cookies sent with redirects. Fortunately, CGI.pm also supports it, though you have to dig a bit to be sure. The CGI pod indeed does not mention such a procedure, but it is supported. Browsing the code of the redirect sub in CGI.pm you can see:

#### Method: redirect
# Return a Location: style header
#
####
'redirect' => <<'END_OF_FUNC',
sub redirect {
    my($self,@p) = self_or_default(@_);
    my($url,$target,$cookie,$nph,@other) = $self->rearrange([[LOCATION
+,URI,URL],TARGET,COOKIE,NPH],@p);
    $url = $url || $self->self_url;
    my(@o);
    foreach (@other) { tr/\"//d; push(@o,split("=",$_,2)); }
    unshift(@o,
         '-Status'=>'302 Moved',
         '-Location'=>$url,
         '-nph'=>$nph);
    unshift(@o,'-Target'=>$target) if $target;
    unshift(@o,'-Cookie'=>$cookie) if $cookie;
    unshift(@o,'-Type'=>'');
    return $self->header(@o);
}
[download]

Note in particular the -Cookie bit. And nicely enough, this actually works as intended. I've used bits like the following successfully:

$cookie = cookie(
  -name    => $COOKIE_NAME,
  -value   => $session_key,
  -expires => $COOKIE_EXPIRE,
  -path    => $SCRIPT_PATH,
  -domain  => $SCRIPT_DOMAIN,
  -secure  => 0
  );

...

print redirect( -uri => 'view.cgi', -cookie => $cookie );
[download]

I admit I'm not sure why OP's bit fails. r.jospeh, take a look at the cookie files for the site you're connecting to in order to make sure they're correct. Offhand, I'd suspect (like dvergin) a difference in $in{usr} and $usr is the problem. If not, you could set up a dirty HTTP server (with HTTP::Daemon, for instance) to see what's going on with your logout cookie.

He re is part of my program:

use CGI;
$query = new CGI;

sub logout {
    $cookie_expires = "-1s";
    &cookie_create;
    print $query->redirect( -uri => $redirect_to, -cookie => $cookie )
+;
}

sub cookie_create {
    $cookie = $query->cookie(-name => $cookie_name,
                              -expires => $cookie_expires,
                              -domain  => $cookie_domain,
                              -path    => $cookie_path,
                              -value=>{ username => $username,
                                      password => crypt($password, $us
+ername) }
                               );
}
[download]

As you can see cookie_create sub can be also used to create cookie not only to erase it. This worked well, if you want all script which verify login again csv flat file user database I can send it to you.

Good luck

Li Tin O've Weedle
mad Tsort's philosopher

Because I tested it locally with my cache folder open - the cookie didn't expire, and I will still able to access all the site's functions. However, many MANY good ideas have been brought up, and I thank everyone for your input. I think I will end up combining many facets of these suggestions to find a solution. Thanks a bunch!

r. j o s e p h
"Violence is a last resort of the incompetent" - Salvor Hardin, Foundation by Issac Asimov