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 17:00:57 GMT
On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller <apache@s05.tinita.de> wrote:

> On Wed, 16 Sep 2009, Michael Peters 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.
>>
>
> How does the user invalidate that "session"? (in case the cookie leaked
> or something like that). Or how can the website owner log out a certain
> user?
>

Same way you do with a table: when the user logs out, you update their
cookie to a new one, where "userid" is not set.



> If I have a session cookie with data in the server database I can always
> invalidate that session by login out and thus removing the database
> entry.
> I personally prefer to have control over such things...
>
> Is one select per request that bad? if the website is completely
> dynamic you will probably have other requests as well?
>
>
Well, the cookie table is the one that gets hit a lot and grows out of
control. It is hard to scale and replicate. Storing cookies on the browsers
solves this completely. I can have a billion browsers connect to my site and
no database growth will occur from that.



> If you care about the number of selects you should IMHO better safe those
> with the help of caching.
>

Mime
View raw message