CGI Cookie Inconsistencies

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

I'm having a problem where a few users on my web application cannot login because their cookie isn't being stored. I'm using the following code:

my $sessionidCookie = $cgi->cookie(
-name => 'sessionid',
-value => $sessionid,
-expires => '+5h');
        
print $cgi->redirect(-cookie => $sessionidCookie,-uri => './?a=');
[download]

and to retrieve:

my $sessionid = $cgi->cookie("sessionid");
[download]

It works on my browser and most others, but there are a select few that the cookies don't get saved. I made sure their browsers are set to "medium" privacy (just as mine and many other working computers are). I also had them go to a cookie testing website, which said that cookies where enabled. Why would a select few users not be able to store cookies on just my website? I had them test on IE Chrome and Firefox all with the exact same results. I've tried just about everything, but I'm hoping I'm just overlooking some new standard or something.

Comment on CGI Cookie Inconsistencies Select or Download Code

Replies are listed 'Best First'.
Re: CGI Cookie Inconsistencies by Your Mother (Archbishop) on Nov 05, 2009 at 05:05 UTC
You're overlooking an old standard. Most browsers/servers do the right thing and it might not be your issue but following the spec is better. URIs in redirects are supposed to be absolute- `use URI (); my $uri = URI->new( $cgi->url ); ( my $path = $uri->path ) =~ s![^/]+\z!!; $uri->path( $path \|\| "/" ); $uri->query_form( a => undef ); print $cgi->redirect(-cookie => $sessionidCookie, -uri => $uri);` [download] Untested but it looks right.	[reply] [d/l]
Re^2: CGI Cookie Inconsistencies by ranqor (Initiate) on Nov 05, 2009 at 05:12 UTC
The redirect part works just fine for all users, would the URI somehow be affecting the cookie even though it redirects as expected? I'm in the unique position of not being able to reproduce the issue here (if someone knows how to reproduce this issue, that would be a huge help), so if I present a fix to the users I want to be almost certain its going to work.	[reply]
Re^3: CGI Cookie Inconsistencies by Your Mother (Archbishop) on Nov 05, 2009 at 05:25 UTC
It might not be the/a problem but I can see it dropping the other headers while doing a redispatch depending on the engine. This issue caused an extremely bizarre and maddeningly difficult bug in some modperl I worked on once (it would execute an entirely unrelated handler on some relative redirects). The point here being, it's wrong as is and when you break standards you get unspecified behavior whether or not it's causing the bug your users are reporting. Try patching it. Verify it's reasonable in your own environment (I didn't test it though I've done a lot of this stuff) then push it out to a user who is seeing the bug and get some feedback.	[reply]
Re^4: CGI Cookie Inconsistencies by ranqor (Initiate) on Nov 05, 2009 at 06:03 UTC
Re^5: CGI Cookie Inconsistencies by ranqor (Initiate) on Nov 08, 2009 at 01:30 UTC
Some notes below your chosen depth have not been shown here
Re^2: CGI Cookie Inconsistencies by Anonymous Monk on Nov 05, 2009 at 08:17 UTC
Oh mother! OBTAINING THE SCRIPT'S URL `print $cgi->redirect( -cookie => $sessionidCookie, -uri => url(-relative=>1).'?a=', );` [download] :D	[reply] [d/l]
Re^3: CGI Cookie Inconsistencies by Your Mother (Archbishop) on Nov 05, 2009 at 17:10 UTC
`./` is likely only be the same directory as the script and not the script's URI so your suggestion is broken (not absolute) and likely to be wrong since most folks don't setup their CGIs to dispatch to "directory" names. :)	[reply] [d/l]
Re^4: CGI Cookie Inconsistencies by Anonymous Monk on Nov 08, 2009 at 10:42 UTC
Re^5: CGI Cookie Inconsistencies by Your Mother (Archbishop) on Nov 08, 2009 at 21:28 UTC
Some notes below your chosen depth have not been shown here
Re^3: CGI Cookie Inconsistencies by Anonymous Monk on Nov 05, 2009 at 08:20 UTC
Err, you want `-absolute => 1` or `CGI->new({a =>''})->self_url` [download]	[reply] [d/l] [select]