You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Jeffrey W. Baker" <jw...@acm.org> on 2002/02/13 21:00:18 UTC
Cookie as session store
I have sometimes proposed or recommended schemes of storing session
information in an HTTP cookie, encoded and protected by cryptographic
digest. I know some people on this list have implemented similar
schemes, but I have never actually had occasion to do so. Now I am
doing that, and I realize the chief drawback to this scheme: all session
information has to be set before generating any HTML output. The chief
advantage is no requirement for server-side storage of session.
For certain applications, saving all output until the session is
serialized may significantly increase the latency of the first data
packet in the HTTP response.
-jwb
Re: Cookie as session store
Posted by Tatsuhiko Miyagawa <mi...@edge.co.jp>.
On Thu, 14 Feb 2002 11:35:14 -0500
"Perrin Harkins" <pe...@elem.com> wrote:
> It's really a good idea to do this even when the cookie is nothing but a
> session ID. A standard module for this like the one Jay mentioned would
> definitely be nice.
Apache::Cookie::Encrypted seems to be the one.
http://search.cpan.org/search?dist=ApacheCookieEncrypted
--
Tatsuhiko Miyagawa <mi...@bulknews.net>
Re: Cookie as session store
Posted by Perrin Harkins <pe...@elem.com>.
> I dunno... That sounds lie a LOT of overhead for just a session ID
> that's gonna result in server lookups too...
It's really not. It adds a negligeble amount of time to the request. As
Jeffrey pointed out, the functions he's using are all in C and very fast.
Why verify session IDs? To make it hard to hijack sessions. This way it
isn't enough to just guess someone else's session ID: you also have to know
how to generate the proper digest for it.
This is also useful to prevent people from screwing up your stats with bogus
IDs. Many people log the session ID for use in calculating people's path
through the site and similar things. Often this is done for pages that
don't actually retrieve the session data from the backend store. Being able
to verify that you have a valid session without hitting your data store can
be very useful.
- Perrin
Re: Cookie as session store
Posted by Issac Goldstand <ma...@beamartyr.net>.
Perrin Harkins wrote:
>>When the cookie is recovered, I simply decode, uncompress, thaw, check
>>the digest, and thaw the inner object.
>>
>
>It's really a good idea to do this even when the cookie is nothing but a
>session ID. A standard module for this like the one Jay mentioned would
>definitely be nice.
>
I dunno... That sounds lie a LOT of overhead for just a session ID
that's gonna result in server lookups too...
Issac
Re: Cookie as session store
Posted by Perrin Harkins <pe...@elem.com>.
> When the cookie is recovered, I simply decode, uncompress, thaw, check
> the digest, and thaw the inner object.
It's really a good idea to do this even when the cookie is nothing but a
session ID. A standard module for this like the one Jay mentioned would
definitely be nice.
> My strategy for document generation is to build a DOM tree and then
> create the output by serializing the DOM to XML or HTML. So, it is
> natural in this application to just set everything up before sending the
> response.
Since I usually structure my applications to do all the work and then pass
some data to a template, they also follow this order. The main problem I
see with sending some HTML before the work is complete is that if something
goes wrong later on you have no way to send a nice error page out. I
sometimes see people having this problem on sites I visit: I get an OK
response and some HTML and then a second set of headers with an error code
and it looks like garbage in a browser.
- Perrin
Re: Cookie as session store
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Thu, 2002-02-14 at 06:17, Jay Lawrence wrote:
> Jeffrey - interesting point!
>
> What did you have in mind to encrypt the cookie data? Perhaps you could use
> Storable to serialize data structure then convert, crypt to scramble and
> then MIME64 to text encode?
I am not encrypting the session data in this system, because the
contents are not sensitive. I base64 encode a gzipped Storable-frozen
object, which contains another Storable-frozen object and the SHA1
digest of itself.
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object. The code is simple:
sub realize_session {
my ($foo) = @_;
my ($i, $s);
$i = thaw(uncompress(decode_base64($foo)));
if (sha1_hex($i->{content} . BIG_SECRET) eq $i->{hash}) {
$s = thaw($i->{content});
return $s;
}
return undef;
}
sub serialize_session {
my ($s) = @_;
my ($i, $frz, $foo);
$frz = nfreeze($s);
$i = {
content => $frz
, hash => sha1_hex($frz . BIG_SECRET)
};
$foo = encode_base64(compress(nfreeze($i)));
return $foo;
}
It's fortunate that all of these functions are fast. Base64, Zlib,
Storable, and SHA1 are all implemented in C.
> I agree with you on processing delays - that is probably the biggest
> drawback to needing to send cookies as part
> of response header. Using Template Toolkit a lot myself, I have to make a
> workaround to handle the cookie situation
> as well.
My strategy for document generation is to build a DOM tree and then
create the output by serializing the DOM to XML or HTML. So, it is
natural in this application to just set everything up before sending the
response. But I can imagine that if you wanted an intermediate page,
progress indications, and so forth you might have to jump through hoops.
> I've got a tied interface to Apache::Cookie's mostly completed - it would be
> easy to add the encryption that you describe above to
> them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
> Featuring tied interface and lazy (demand) loading of cookie data.
Thanks!
-jwb
Re: Cookie as session store
Posted by Jay Lawrence <Ja...@Lawrence.Net>.
Jeffrey - interesting point!
What did you have in mind to encrypt the cookie data? Perhaps you could use
Storable to serialize data structure then convert, crypt to scramble and
then MIME64 to text encode?
I agree with you on processing delays - that is probably the biggest
drawback to needing to send cookies as part
of response header. Using Template Toolkit a lot myself, I have to make a
workaround to handle the cookie situation
as well.
I've got a tied interface to Apache::Cookie's mostly completed - it would be
easy to add the encryption that you describe above to
them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
Featuring tied interface and lazy (demand) loading of cookie data.
Jay
----- Original Message -----
From: "Jeffrey W. Baker" <jw...@acm.org>
To: <mo...@apache.org>
Sent: Wednesday, February 13, 2002 3:00 PM
Subject: Cookie as session store
> I have sometimes proposed or recommended schemes of storing session
> information in an HTTP cookie, encoded and protected by cryptographic
> digest. I know some people on this list have implemented similar
> schemes, but I have never actually had occasion to do so. Now I am
> doing that, and I realize the chief drawback to this scheme: all session
> information has to be set before generating any HTML output. The chief
> advantage is no requirement for server-side storage of session.
>
> For certain applications, saving all output until the session is
> serialized may significantly increase the latency of the first data
> packet in the HTTP response.
>
> -jwb
>
>
>
>