Re: Cookie as session store
On Thu, 14 Feb 2002 11:35:14 -0500 Perrin Harkins [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Cookie as session store
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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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
Re: Cookie as session store
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
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
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
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
