HTTP Sessions

[Matthew J. Long]

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