Re^2: accessing session variables across different pages

Okay, I need someone to say me from giving up on Perl to perform this basic task. I've literally taken a code example from CPAN for checking an existing session and it STILL doesn't recognize a session!!!! Here is the code:

use strict;
use CGI::Session;
use CGI;
use CGI::Cookie;

print "Content-type: text/html\n\n";
my $cgi = new CGI("CGISESSID");
my $session = CGI::Session->load or die CGI::Session->errstr;
print $session->header;
if ($session->is_expired) {
  print $session->header,
    $cgi->start_html,
     $cgi->p("Your session timed out. Click here to start a new sessio
++n."),
   $cgi->end_html;
  exit(0);
}
if($session->is_empty) {
  print $cgi->start_html;
  print "Click here to sign in";
  print $cgi->end_html;
  exit(0);
}

print "</body>";
print "</html>";
[download]

Problem: I've created a valid session from the another login page. However, when I place the above code at type of another page, it always evaluates to an empty session. I've seen another post similar to this one and not one really answered the question. Is there some conspiracy against using Perl for session management? Should I just throw my hands up and use PHP Session_Start()?

Comment on Re^2: accessing session variables across different pages Download Code

Replies are listed 'Best First'.
Re^3: accessing session variables across different pages by moritz (Cardinal) on Mar 08, 2009 at 23:47 UTC
You have other means of debugging, too: Look in your browser's cookie jar if it's stored in there If it is, follow the HTTP requests with a network traffic analyzer like wireshark to see if it's sent to the server If it is, print the return value of CGI.pm's `cookie()` sub. Most likely it will stop to appear at one of these steps. Knowing which step it is might help you to find out what's wrong.	[reply] [d/l]
Re^3: accessing session variables across different pages by Anonymous Monk on Mar 08, 2009 at 23:48 UTC
Try `CGI::Session->retrieve()` again? http://cpansearch.perl.org/src/MARKSTOS/CGI-Session-4.40/examples/subscriptions.cgi `my $cgi = new CGI(); my $session = CGI::Session->load() or die CGI::Session->errstr; if ( $session->is_expired ) { print $session->header(); print "Your session expired, inevitably!"; exit(0); } elsif ( $session->is_empty ) { $session = $session->new(); }` [download] CGI::Session `$s = CGI::Session->load() or die CGI::Session->errstr(); if ( $s->is_expired ) { print $s->header(), $cgi->start_html(), $cgi->p("Your session timed out! Refresh the screen to sta +rt new session!") $cgi->end_html(); exit(0); } if ( $s->is_empty ) { $s = $s->new() or die $s->errstr; }` [download]	[reply] [d/l] [select]
Re^3: accessing session variables across different pages by Your Mother (Archbishop) on Mar 09, 2009 at 03:35 UTC
Ah, I think this is an XY Problem. A session existing in no way means an authenticated or valid user. And the fact that a user can supply a cookie named CGISESSID should not allow them to appear as "signed-in." I don't WANT want one to be created, I just want to check for the existence of one. If it doesn't exist, sendt the user to the login page. Not really. What you want to do is check if the session is valid. So, long story short, you can do what you are trying to. It will be verbose however and it will not remove any of the code you'll have to do to check that the session is valid so it's probably pointless unless you've got a high traffic site and don't want to hit the DB with new empty sessions all the time. If you do want to do it this is the flow- Use CGI::cookie() to read the cookie named "CGISESSID" or "YOUR_CUSTOM_NAME." If it exists and has a reasonable value, try to load it from CGI::Session->load(). If it's valid, pass/send them along to /home or whatever (there can be many reasons it wouldn't be valid; wrong/new IP, DB says session is too old to still be valid, some other token of your devising doesn't match the last request for that session). If it's not valid, send them to the login page. If it doesn't exist, send them to the login page. The thrust being, you have to create a session to validate one so the only benefit of not doing so is avoiding some overhead and if you have a 100% login access site anyway you won't be saving much. :)	[reply]