in reply to accessing session variables across different pages

AM above was right though probably not helpful for you. There is no such method as retrieve in CGI::Session. The session and cookie handling are done by creating a new object. You can configure it many different ways but it should work out of the box with tmp files and an auto-named cookie following the examples directly.

# (mostly) From the tutorial link above- use strict; # Important! use warnings; # Ditto! my $session = CGI::Session->new() or die CGI::Session->errstr; Above line will first try to re-initialize an existing session by cons +ulting cookies and necessary QUERY_STRING parameters. If it fails wil +l create a brand new session with a unique ID, which is normally call +ed session ID, SID for short, and can be accessed through id() - obje +ct method. We didn't check for any session cookies above, did we? No, we didn't, +but CGI::Session did. It looked for a cookie called CGISESSID, and if + it found it tried to load existing session from server side storage +(file in our case). If cookie didn't exist it looked for a QUERY_STRI +NG parameter called CGISESSID. If all the attempts to recover session + ID failed, it created a new session.

I know you said you spent hours reading CPAN docs so you might have seen it already but that tutorial is pretty direct and you're not likely to get a better answer anywhere. Your username prompts the following jest-

s/(?<=Reading )[^.]+(?=.)/is fundamental/;

I know how frustrating some of this can be at first. I've done the same hours of reading or 500 permutations on a theme based on an assumption. But stick with it. It gets more fun all the time. :)

Oh, all right. Just thinking about the days I wasted early on because I was just missing some simple piece... Here, you go, a minimal working example. You should be able to play with configuration and code order pretty easily from this-

use strict; use warnings; use CGI::Session; use CGI qw( h1 p ); use CGI::Carp "fatalsToBrowser"; my $session = CGI::Session->new or die CGI::Session->errstr; print $session->header(); if ( $session->param("visits") ) { print h1("Welcome back!"); print p( sprintf("You've been here %d time%s.", $session->param("visits"), $session->param("visits") == 1 ? "" : "s", ) ); } else { print h1("Welcome first time visitor"); } $session->param( visits => $session->param("visits") + 1 );

Replies are listed 'Best First'.
Re^2: accessing session variables across different pages
by s/^Perl/pain/i (Initiate) on Mar 08, 2009 at 23:38 UTC
    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>";
    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()?
      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.
      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(); }
      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; }

      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. :)