HTTP Sessions

[Keary Suska]

> It just seems strange to me that there is not a simpler abstraction of this.
> In PHP4, for instance, you can create a session object and store variables
> between pages without giving it much thought. This doesn't appear to write a
> cookie either, so I'm not sure how it works in PHP, but I figured there
> should be something as simple as this to use with perl.

There probably is--I was simply describing the internal mechanics. For
instance, with PHP, you have two session tracking options: 1) cookies; 2)
embedded identifiers. How sessions are handled is determined by a
configuration setting, which I believe can be altered at run time. PHP
handles all this for you: in option #2, PHP will automatically parse all
output for links and append the session identifier to it. I don't recall how
or if PHP works on forms in this way. PHP stores session info in a file
under /tmp (by default), and handles its own cleanup, for both methods.

I would be surprised if there isn't some equivalent in Perl, although I am
not aware of any. I was responding to methods for session tracking rather
than particular modules for doing so. I personally tend to go for home grown
solutions since modules have a tendency to be a "one size fits all" and
hence have a tendency to bloat CGI scripts, which is often not desirable in
a high-volume web environment with a restricted budget (of which I am
accustomed to work in).

Maybe this will show something of use:
    http://search.cpan.org/search?mode=module&query=session

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"

> From: "Matthew J. Long" <matt.long at matthew-long.com>
> Date: Fri, 7 Dec 2001 12:09:25 -0700
> To: "Keary Suska" <aksuska at webflyer.com>, "Pikes Peak Perl Mongers"
> <pikes-peak-pm-list at happyfunball.pm.org>
> Subject: Re: HTTP Sessions
> 
> It just seems strange to me that there is not a simpler abstraction of this.
> In PHP4, for instance, you can create a session object and store variables
> between pages without giving it much thought. This doesn't appear to write a
> cookie either, so I'm not sure how it works in PHP, but I figured there
> should be something as simple as this to use with perl. What I'd really like
> is an interface for writing my own perl objects that can be easily
> persisted. For instance, something like this would be nice:
> 
> # create the session
> my $session = new HTTP::Session();
> 
> my $object = new MyObject($session); # sets on the object will update the
> value in the session object.
> 
> $object->setName("New MyObject Object");
> 
> $session->store();
> $session->close();
> 
> # use the session later in another CGI
> my $session = HTTP::Session::getSession();
> 
> my $object = new MyObject($session); # session values are assigned to the
> appropriate instance variables upon instatiation
> 
> my $name = $object->getName();
> 
> print "Content-type: text/html\n\n";
> 
> print "The object name is: $name<br>\n";
> 
> print $session->close();
> 
> etc.....
> 
> ---------------------------------------------------------
> 
> I suppose I could write this, but it would have to use a cookie, I suppose.
> That's the way I usually implement sessions, anyhow, so no biggie. I just
> thought that since PHP had something like this, Perl must!! Thanks for your
> help.
> 
> -Matt
> 
> 
> 
> ----- Original Message -----
> From: "Keary Suska" <aksuska at webflyer.com>
> To: "Pikes Peak Perl Mongers" <pikes-peak-pm-list at happyfunball.pm.org>
> Sent: Friday, December 07, 2001 11:46 AM
> Subject: Re: HTTP Sessions
> 
> 
>> On the client side, there are essentially only two methods: cookies and
>> embedded links (or a combination of the two). On the server side, it is
>> simply a matter of storing the session info as a persistent data
> structure,
>> such as a database or plain file. IMHO, cookies are less work, but you
> have
>> to consider that some clients will refuse them. Embedded links (i.e.
>> embedding a session identifier in links and forms) are more work for at
>> least the server (there may be modules that automate this process), since
>> they have to parse every page applicable. This not really an issue if all
>> the pages are dynamically generated (from within the CGI), but it can be a
>> pain to maintain. Political considerations (such as allowing users to
> refuse
>> cookies and still use the site) may give weight to one or the other
>> implementation. None of these require special access to the server system,
>> since you can use /tmp or a designated directory in cgi-bin/ for storing
>> files if you don't have database access.
>> 
>> If your are using CGI.pm, cookie handling is built in, so you don't need
>> other modules. There is a method I have used that can be easier to
> maintain
>> for an "embedded link" implementation using PATH_INFO. When the user first
>> accesses the CGI, say, at /cgi-bin/session.cgi, without a valid session
>> identifier (if they expire), they are redirected to
>> /cgi-bin/session.cgi/session_id. from that point on, all relative links
> will
>> have /cgi-bin/session.cgi/session_id prepended, so all you have to do is
>> parse the PATH_INFO to get the session id and page that needs to be
>> displayed. The drawback to this approach is that all external files loaded
>> from the page by the client (such as images and .js files) must have
>> absolute path names (unless they are to be routed through the CGI), and to
>> get "out" of the session tracked area an absolute path name is required
> (or
>> the CGI can recognize the file as external and redirect the client to it).
>> 
>> I tend to use mod_unique to get unique session identifiers under Apache,
> but
>> if that is not available, a base-64 encoded string comprised of the date
> and
>> time (MMDDYYYYHHMMSS or something like that) plus a randomly generated
>> integer is often sufficient.
>> 
>> P.S. I don't think there was a luncheon this time--I didn't hear about one
>> either.
>> 
>> Keary Suska
>> Esoteritech, Inc.
>> "Leveraging Open Source for a better Internet"
>> 
>> From: "Matthew J. Long" <matt.long at matthew-long.com>
>> Date: Fri, 7 Dec 2001 10:02:32 -0700
>> To: "Pikes Peak Perl Mongers" <pikes-peak-pm-list at happyfunball.pm.org>
>> Subject: HTTP Sessions
>> 
>> 
>> Seems like there's a lot of different modules for creating sessions for a
>> CGI. Can anyone recommend the best way to implement sessions considering
>> that I don't have root access to my web server (hosted)?
>> 
>> Thanks.
>> 
>> -Matt
>> 
>> p.s. Did I miss a meeting yesterday? I don't remember seeing any messages
> on
>> it.
>> 
>> 
>> 
> 
>