This? http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm
Catalyst has a plugin: http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.35/lib/Catalyst/Plugin/CookiedSession.pm Thanks. On Fri, Sep 18, 2009 at 9:06 PM, Igor Chudov <ichu...@gmail.com> wrote: > Michael, you inspired me to reimplement cookies this way. For my site, the > cookie table is the most frequently updated one (even though I do not grant > cookies to search engines). I will try to use this kind of implementation. > > Even now, my users like the fact that they can stay signed on forever, but > now I can do it at no cost to myself. > > A quick question, is there an existing perl module to do this sort of thing? > > Igor > > On Wed, Sep 16, 2009 at 12:11 PM, Michael Peters <mpet...@plusthree.com> > wrote: >> >> On 09/16/2009 12:13 PM, Brad Van Sickle wrote: >> >>> Can I get you to explain this a little more? I don't see how this could >>> be used for truly secure sites because I don't quite understand how >>> storing a hash in a plain text cookie would be secure. >> >> If you need to store per-session data about a client that the client >> shouldn't be able to see, then you just encrypt that data, base-64 encode it >> and then put it into a cookie. >> >> If you don't care if the user sees that information you just want to make >> sure that they don't change it then add an extra secure hash of that >> information to the cookie itself and then verify it when you receive it. >> >> I like to use JSON for my cookie data because it's simple and fast, but >> any serializer should work. Something like this: >> >> use JSON qw(to_json from_json); >> use Digest::MD5 qw(md5_hex); >> use MIME::Base64::URLSafe qw(urlsafe_b64encode urlsafe_b64decode); >> >> # to generate the cookie >> my %data = ( foo => 1, bar => 2, baz => 'frob' ); >> $data{secure} = generate_data_hash(\%data); >> my $cookie = urlsafe_b64encode(to_json(\%data)); >> print "Cookie: $cookie\n"; >> >> # to process/validate the cookie >> my $new_data = from_json(urlsafe_b64decode($cookie)); >> my $new_hash = delete $new_data->{secure}; >> if( $new_hash eq generate_data_hash($new_data) ) { >> print "Cookie is ok!\n"; >> } else { >> print "Cookie has been tampered with! Ignore.\n"; >> } >> >> # very simple hash generation function >> sub generate_data_hash { >> my $data = shift; >> my $secret = 'some configured secret'; >> return md5_hex($secret . join('|', map { "$_ - $data->{$_}" } keys >> %$data)); >> } >> >> Doing encryption and encoding on small bits of data (like cookies) in >> memory will almost always be faster than having to hit the database >> (especially if it's on another machine). But the biggest reason is that it >> takes the load off the DB and puts it on the web machines which are much >> easier to scale linearly. >> >> > I know a lot of true app servers (Websphere, etc..) store >>> >>> this data in cached memory, >> >> You could do the same with your session data, or even store it in a shared >> resource like a BDB file. But unless it's available to all of your web >> servers you're stuck with "sticky" sessions and that's a real killer for >> performance/scalability. >> >> -- >> Michael Peters >> Plus Three, LP > > -- Fayland Lam // http://www.fayland.org/
