Hello, I want to thank all who responded.
It appears I need to bush up on my perl-CGI skills and cookies. The problem I thought I was having was not creating the cookie. However, after more investigation, I found I wasn't reading the browser cookies that were previously created. Apparently the code shown here was creating the cookie. Those who responded indicating the code looked OK were right. The problem I have was not being able to read the cookie back from the browser. In my old perl 5.005 environment, the cookie was created, using the same code, but somehow had the cookie path set to "/cgi-bin/". After porting the code to Solaris Perl 5.6, the cookie path was now being set to "/". The scripts in /cgi-bin were not able to read and access the "state" information stored in the cookie. I'm still not sure why the path defaults to "/" and not "/cgi-bin/". I can't see any code or environment information setting the path. Perhaps it defaults differently in 5.5. I found a simple remedy. I just added the line: "-path=>'/cgi=bin/'" when creating the cookie. After adding this line and running the script, it appears to be working correctly. Thank-you for your input. Kirk W. Batzer [EMAIL PROTECTED] -----Original Message----- From: Curtis Poe [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 31, 2001 12:34 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Debugging tips: Re: Cookies stopped working --- "Kirk W. Batzer" <[EMAIL PROTECTED]> wrote: > I'm attempting to port a perl CGI application > from: "perl, 5.005_02 built for 3446-svr4.0" > to: "perl, v5.6.1 built for sun4-solaris" > > The application uses "cookies" to maintain "state" information. The > following code is successfully creating and using cookies in the perl > 5.5 , but failing to create cookies in the perl 5.6 environment. > > ====================== > use CGI qw(:standard); > use MIME::Base64; > .......... > %mylist = &SelectFromTable(*table, *collist, *wherelist); > > local(@userinfo) = ( $mylist{userid}, > $mylist{usertype}, > $mylist{username}, > $mylist{phone}, > $mylist{groupname}, > $mylist{email}); > > local($user) = encode_base64( join(":", @userinfo) ); > > $cookie = cookie( -name=>'loginfo', > -value=>$user, > ); > print header(-cookie=>$cookie); > > =========================== Kirk, The code above looks fine. However, since we're only seeing a portion of the code, it's quite possible that there is something else in the code that could be causing an issue. For example, since you do not appear to be using strict, you may have a typo in a variable name that doesn't show up. Have you verified that &SelectFromTable is actually populating %mylist? Common debugging technique when using cookies: When you set the cookie, write the cookie to the error log in addition to sending it in the headers. 1. What's the expiration on the cookie? If your computer's time is off, this could cause a problem. 2. What's the domain? This is the biggest source of 'porting' errors that I have seen. Make sure that the domain the cookie has is the *same* as the domain to which you intend to send the cookie! Sometimes when porting apps, the developers still has form tags and links pointing to another domain. This will break your cookies. Also, does the domain have at least two dots? 3. What's the path? If the path says /admin/cgi-bin/, cookies will only be sent to that path and extensions of that path. They will not be returned to /admin/. 4. Is the secure flag set? I once had a heck of a time trying to figure out why an administrative console of my wouldn't set cookies until I realized that we had moved the site and forgotten the SSL certificate. Cookies sent as "secure" will only be returned over an encrypted connection. 5. Is there a typo in the name? In the script that should receive the cookie, but isn't, try the following (assume the CGI object is named $query): use Data::Dumper; my $cookie_val = $query->cookie( 'loginfo' ); warn Dumper $query; That will dump the details of your CGI object to your error log. It's ugly, but it works. You can then check to see if any cookies have been set. Note that (at least on my version of CGI.pm) you have to try to assign one of the cookie values to get the cookies added to the CGI object. In the event that you are using the function oriented interface, you can use the following trick: use CGI qw/:standard/; my $cookie_val = cookie('id'); my $cgi = &CGI::self_or_default; warn Dumper $cgi; The &CGI::self_or_default method should return the CGI object that CGI.pm uses internally. Here's a test script you can use to verify that cookies are being set. Run this through a browser. You'll have to execute it twice (once to set the cookie and once to get it back). #!D:/perl/bin/perl.exe -w use strict; use Data::Dumper; use CGI qw/:standard/; my $cookie = cookie( -name => 'id', -value => '1234' ); my $cook_val = cookie('id'); my $cgi = &CGI::self_or_default; my $dump = Dumper $cgi; print header(-cookie=>$cookie), pre( header(-cookie=>$cookie) ), start_html, pre( $dump ), end_html; On my machine, after the second time I've executed it, I get the following output in the browser: Set-Cookie: id=1234; path=/ Date: Wed, 31 Oct 2001 17:26:53 GMT Content-Type: text/html; charset=ISO-8859-1 $VAR1 = bless( { '.charset' => 'ISO-8859-1', '.parameters' => [], '.fieldnames' => {}, '.cookies' => { 'id' => bless( { 'path' => '/', 'value' => [ '1234' ], 'name' => 'id' }, 'CGI::Cookie' ) } }, 'CGI' ); Note that the cookie is clearly visible. I've also added the header to the body of the document so you can see what the browsers getting. Good luck! Cheers, Curtis "Ovid" Poe ===== Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
