Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

The cookie crumbles

by Siddartha (Curate)
on Oct 24, 2001 at 13:03 UTC ( [id://121039]=perlquestion: print w/replies, xml ) Need Help??

Siddartha has asked for the wisdom of the Perl Monks concerning the following question:

I am having a few problems with cookies.

My script worked perfectly until we did some maintenance on the servers and upgraded the firewall. Now suddenly my script doesn't want to create cookies anymore. My script haven't changed and the apache config looks the same.

I have no idea where to start looking for problems.

Here is a snippet of code:

$query = new CGI; # $menu and $name is passed to this script # $menu is not defined when the script is called the first time if (!(defined($menu))) { if (!(defined($name))) { print $query->redirect(' +gin.cgi'); }; my $cookie_name = $query->cookie("name"); if ($cookie_name ne $name) { my $cookie = $query->cookie (-name => 'name', -value => $name, -domain => '', -expires => '+10y'); my $myurl = ''.$nam +e; #This redirects to the same script print $query->redirect (-cookie => $cookie, -uri => $myurl); exit 0; }; } else { my $cookie_name = $query->cookie("name"); $name = $cookie_name; };

The script relies on the cookie being set, if not it calls the same URL and sets the cookie. What seems to happen is that it is calling the same script over and over and never sets the cookie. I am sure that the browser I am testing it on accepts cookies.

Any ideas would be appreciated, I have no idea where to start. I took out the checking part and everything works perfectly.


Replies are listed 'Best First'.
Re: The cookie crumbles
by Masem (Monsignor) on Oct 24, 2001 at 15:03 UTC
    First, always check to see if the cookie is being created on your browsing end, since this is rather simple to do. That would help to narrow down the problem of what might be going on. Also test it with multiple browsers from different vendors, as they handle cookies slightly differently and that might help narrow it down more. My gut feeling is that there's something with the firewall such that the domain or the like that you are setting cookies with doesn't match up with the real domain name, and 3rd party cookies are usually ignored or something turned off by a user.

    You may want to replace:

    my $myurl = ''.$name;
    my $myuri = $query->self_url();
    which basically returns the URL to the script along with all CGI parameters in place.

    Dr. Michael K. Neylon - || "You've left the lens cap of your mind on again, Pinky" - The Brain
    "I can see my house from here!"
    It's not what you know, but knowing how to find it if you don't know that's important

      Thanks for your reply.

      I have tested it with Netscape and IE on Pc and Mac, and it doesn't work on any. Netscape says "document contains no data".

      By changing to:
      my $myuri = $query->self_url();
      I still get the same problem. I prefer not to use it, since I only want to pass the one parameter if the cookie was not found.

      Any more ideas would be welcomed. I am currently looking at the firewall, but don't see any obvious problems. the domain is exactly the same, there is only one domain name.


        There might be a problem between setting a cookie followed by a redirect (I know, there shouldn't be one, but...). Try, instead of printing that redirect for the time being, print a simple page, to see if that part of the loop is even being seen.

        Try to print to either the web page or to the log file the values of $menu and $name, ideally bracketed as in "--$name--", in case that your firewall might be adding extra characters to the end. If anything, try replacing the not-equal comparison with a regex (  if ( $name !~ /$cookie_name/ ) ....

        As for the script referencing, I would suggest that it's always better to let the cgi determine where it is than for you to specify it; that's one less place where a site setting could go amiss if you have to move servers. You can delete all the other CGI params except for name using:

        foreach my $param ( $query->params() ) { $query->delete( $param ) if ( $param ne 'name' ); }
        and then use the self_url to leave only the name param and the right script location. That (probably) won't fix your problem; it's only a style issue.

        Dr. Michael K. Neylon - || "You've left the lens cap of your mind on again, Pinky" - The Brain
        "I can see my house from here!"
        It's not what you know, but knowing how to find it if you don't know that's important

Re: The cookie crumbles
by joealba (Hermit) on Oct 24, 2001 at 16:29 UTC
    First: Change your -domain line to:

         -domain => ''
    You need at least two periods in the domain line (to make sure you don't try to set a domain-wide cookie across a top level domain like .com or something).

    Second: I prefer to use CGI::Cookie. I've never had a problem with it.

    use CGI::Cookie; my $c = new CGI::Cookie( -name => 'COOKIENAME', -value => 'Whosyerdaddy', -expires => '+1M', -domain => '' ); print "Set-Cookie: $c\n";
    my %temp = parse CGI::Cookie($ENV{HTTP_COOKIE}); my %cookies; foreach (keys %temp) { $cookies{$_} = shift @{$temp{$_}{value}}; }
    I'm not sure why parse returns an array of values for each cookie, but it does. Yes, I could have used map, but I haven't had my coffee yet this morning. :)

    print header(); my $debug = 1; # READ COOKIE CODE if ($debug) { foreach (keys %cookies) { print "$_: $cookies{$_}<BR>\n"; } }
    Redirect to a simple little script that runs this code. That should tell you how well your cookies worked.
      Thanks for the info.

      I have solved the problem though. With the general admin on the servers, the server suddenly decided it was 1970 instead of 2001. this is why all my cookies were being killed.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://121039]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (4)
As of 2024-04-13 00:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found