On Fri, Sep 18, 2009 at 8:12 AM, Fayland Lam <fayl...@gmail.com> wrote:
> This? > http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm<http://search.cpan.org/%7Ejkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm> > > Catalyst has a plugin: > > http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.35/lib/Catalyst/Plugin/CookiedSession.pm<http://search.cpan.org/%7Elbrocard/Catalyst-Plugin-CookiedSession-0.35/lib/Catalyst/Plugin/CookiedSession.pm> > > This module seems to want libapreq.1-34, which I interpret as not being compatible with mod_perl 2? I tried installing it with CPAN on Ubuntu Jaunty and failed. CPAN.pm: Going to build I/IS/ISAAC/libapreq-1.34.tar.gz Please install mod_perl: 1.25 < version < 1.99 (Can't locate mod_perl.pm in @INC (@INC contains: /root/misc/life/modules /root/lisleelectric.com /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at Makefile.PL line 7. ) at Makefile.PL line 8. BEGIN failed--compilation aborted at Makefile.PL line 18. Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site] Warning (usually harmless): 'YAML' not installed, will not store persistent state ISAAC/libapreq-1.34.tar.gz /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK Running make test Igor > 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/ >
