[PATCH conductor] BZ 785094 - fixed cookie overflow and session store

Tomas Sedovic tsedovic at redhat.com
Fri Feb 10 09:57:33 UTC 2012


On 02/09/2012 04:54 PM, Jan Provaznik wrote:
> On 02/09/2012 04:00 PM, Matt Wagner wrote:
>> On Thu, Feb 09, 2012 at 11:02:15AM +0100, jprovazn at redhat.com wrote:
>>> From: Jan Provaznik<jprovazn at redhat.com>
>>>
>>> Because of wrong syntax in session_store initializer we used
>>> CookieStore instead of ActiveRecordStore.
>>
>> This isn't a comment on your patch itself, but rather the session store
>> in general.
>>
>> Were we actually overflowing the session cookie? It's allows 4 kB, so if
>> we were overloading that, it seems like we were likely doing something
>> wrong. Switching to the database store to fit more in seems like we're
>> just sweeping the problem under the rug.
>>
>> It might just be that I'm the son of a performance engineer and that I
>> came here from working on a Rails site with a high number of concurrent
>> users, but the cookie store is the one Rails recommends using not just
>> because it's the easiest to set up, but also because it avoids having to
>> track all of this information in a database table that gets updated on
>> most (if not all) requests.
>>
>> In any event, this is almost certainly a post-1.0 thing, but I'm curious
>> if there were compelling reasons to use the ActiveRecordStore beyond
>> allowing us to stash more data into the session?
>>
>> -- Matt
>
>
> We were overflowing the cookie limit because of having too big flash
> object (which is part of the session cookie) in some situations - multi
> select operations, big deployments..., some examples:
> - select 50 instances and click reboot/stop - there is a flash notice
> for each instance if operation was successful or not
> - create a deployment w/ 25 instances, error message is displayed for
> each instance which failed to launch
> - deployment deletion is similar
>
> IOW we exceed the limit because of too long/many messages.

I think that eventually (post 1.0?), we should fix the messages to not 
get so long. It makes for a distracting UI.

For example, if we stop more than 5 instances at once, instead of 
enumerating them all, we'd show something like "28 instances were 
successfully stopped.", possibly with a link to an event list where the 
user can inspect the details.

>
> Agree w/ you about advantages of CookieStore, but it has also one
> disadvantage: whole session is in cookie, a user sees everything stored
> in session, and most users don't delete cookies), so its usage in
> production mode is not so usual. I think it's best to use none of them
> in production state :) - MemcacheStore was my favourite one.

Switching to cookie_store would make us limit the number of data we 
store in the session (auth tokens + the flash messages) which sounds 
like a good practice anyway.

As for users seeing the session data, that's surprised me a lot. I'm 
used to session contents being transparently encrypted -- so the client 
could neither see nor tamper with the session data.

Since the Rails session config contains a :key and :secret values, I 
presumed that the encryption happens here as well, but it turns out that 
this is used for integrity verification only.

Anyway, I agree that using something like Memcached or Redis for this 
purpose would probably be better.

>
> Honestly, I don't think that another ActiveRecordStore will have a
> noticable impact on performance, ATM for each request we do so many
> requests that 2 more requests is a drop in sea.
>
> Jan



More information about the aeolus-devel mailing list