On Mar 22, 11:42 pm, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> If you'd like to coordinate this, I'd definitely be glad to hear from
> them. As it stands I think your complaint boils down to the lack of
> server-side invalidation of a session. Most everything else flows
> from that. I'
On Mar 23, 2007, at 4:47 PM, S. Robert James wrote:
> @Brad - Great work on setting up some code for benchmarking. I
> haven't reviewed your code, but doing nonces correctly gets into some
> sticky synchronization and concurrency. Basically, the system needs
> to make sure that:
>
> * The nonc
On Mar 22, 11:42 pm, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> If you'd like to coordinate this, I'd definitely be glad to hear from
> themI'm not sure that there's a shared nothing way to take
> care of that, but the crypto experts would know for sure.
>
> Please do investigate having
On Mar 23, 2007, at 1:35 PM, Sandofsky wrote:
>
>> 80k cannot go in cookies. On most platforms the limit is 4k. The
>> CookieStore raises an error if you try to store too much.
>
> http://tools.ietf.org/html/rfc2109
>
> "at least 4096 bytes per cookie ... at least 20 cookies per unique
> host or
> 80k cannot go in cookies. On most platforms the limit is 4k. The
> CookieStore raises an error if you try to store too much.
http://tools.ietf.org/html/rfc2109
"at least 4096 bytes per cookie ... at least 20 cookies per unique
host or domain name"
Is there something in today's cookie implemen
On 3/23/07, Jeremy Evans <[EMAIL PROTECTED]> wrote:
> On 3/23/07, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
> > Let's talk about practical fixes rather than whether we should write
> > it off entirely.
...
> > This requires one additional database query on logout to invalidate
> > future reuse o
OK, here it is: svn://svn.madriska.com/plugins/raisin_cookies
To use, install the plugin and start up the DRb server from the DRb
session store (action_controller/session/drb_server.rb).
The DRb server keeps a hash mapping session HMACs to the latest nonce
used with the session. The nonce is
On 3/23/07, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
> Let's talk about practical fixes rather than whether we should write
> it off entirely.
>
> An application-level solution to user_id replay:
>
> Per request:
> @current_user =
> User.find_by_id_and_last_seen_at(session[:user_id],
> sessi
Good points. I worked up a quick plugin that uses DRb to store the
nonce, and I'm doing some benchmarks on it now. I don't have time for
anything fancy, but we can at least get in the ballpark.
Or, to put it in Zed's terms, we'll just run it 100 times each way
and compare the numbers. :-)
On 3/22/07, Brad Ediger <[EMAIL PROTECTED]> wrote:
> On Mar 22, 2007, at 7:27 PM, Jeremy Kemper wrote:
> > Avoiding a single database lookup isn't the purpose of the cookie
> > store.
>
> Sure, but you do remove a lot of the glamour of the cookie store if
> it has to be tied to a database for a no
On Mar 23, 2007, at 3:30 AM, Sandofsky wrote:
>
> Pulling two IDs (session id + nonce) from the DB is better than
> pulling 80k that could go in cookies. Why not include nonce in the
> default, and if the developer wants the blazing speed (and
> corresponding dangers), they can disable it?
80k c
Pulling two IDs (session id + nonce) from the DB is better than
pulling 80k that could go in cookies. Why not include nonce in the
default, and if the developer wants the blazing speed (and
corresponding dangers), they can disable it?
On Mar 22, 5:51 pm, Brad Ediger <[EMAIL PROTECTED]> wrote:
> O
Michael Koziarski wrote:
> That most applications *already* change their session store indicates
> that it's not that big a deal.
My feeling (this is what I did) is that this happens because they *got
bitten* by the default session store problems, the effects are visible
(mainly the performan
13 matches
Mail list logo
