perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Chudov <ichu...@gmail.com>
Subject Re: Ways to scale a mod_perl site
Date Fri, 18 Sep 2009 13:21:57 GMT
On Fri, Sep 18, 2009 at 8:12 AM, Fayland Lam <fayland@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 <ichudov@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 <mpeters@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/
>

Mime
View raw message