perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fayland Lam <fayl...@gmail.com>
Subject Re: Ways to scale a mod_perl site
Date Fri, 18 Sep 2009 13:12:05 GMT
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 <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