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 19:15:41 GMT
On Fri, Sep 18, 2009 at 12:11 PM, James Smith <js5@sanger.ac.uk> wrote:

>  Igor Chudov wrote:
>
>
>
> 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.
>
>
>
> You missed the point in the previous email - that is when the "System" logs
> the user out... User X does something naughty - you need to ban him from
> doing anything else so you
> make his cookie invalid - this information can only occur on the server
> side so you delete the reference in the database refering to this session..
> You are now having to check this
> each time which is the same as getting the information out of the
> database...
>
> I also think that everybody putting lots of stuff in their cookies is not
> thinking about network latency bandwidth etc - remember unless you are very
> careful how you specify your
> cookies you end up sending them on every request - for images/js/css/etc
> this adds to both bandwidth and CPU power - so it's a case of swings and
> roundabouts... balance your
> considerations....
>
> You will usually find a fast right through cache is the best solution for
> most information on the backend... and being careful to only really create
> sessions when you have to!
>

Thanks. I think that I understand the issue a little better.

When I delete someone's account, I blow away everything, their users table
entry, and all their content.

So when they have a cookie with an invalid userid, they cannot do that much
-- but I gotta admit that I need to think this through a little better.

i

Mime
View raw message