-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variable Cookie TTL based on master_ttl #100
Conversation
# determine how lone the cookie TTL should last | ||
# this needs to be done huristically, as we cannot be sure which connection | ||
# would have had the longest timeout from this middleware | ||
def cookie_ttl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't see the new cookie_ttl
setting here. did you mean for the second one to be that?
Should this use the Makara::ConfigParser
or ather, this logic be there ? it provides a way to do the default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, we can't use the Makara::ConfigParser here. There may be many instances of Makara in play (ActiveRecord vs ActiveRabbit, so we won't know which connection to source). I also don't know how we would find the instance at the middleware level.
That's why I tried to hack it with ActiveRecord::Base...
As I can see it right now, this won't solve the whole problem.
If you just increase the cookie TTL, leaving the other mechanics as they are right now, it will stick to master only for one request during this time-frame. As soon as the next request will start, a new Context will be generated, and the cookie will be overwritten with the new context (and this new context is not in cache, so the third request will go back to slaves even though the |
I don't see anywhere where we delete that cookie. if it was there at the beginning of the middleware, it will write it at the end. If anything, i'd be worried that we'd keep writing it over and over forever at the moment. I don't believe |
It's either we are talking about different things or this really works not as you intended This one fails # spec/middleware_spec.rb
it 'should not overwrite existing cookie' do
env['HTTP_COOKIE'] = '_mkra_ctxt=old_context--200; path=/; max-age=5; HttpOnly'
status, headers, body = middleware.call(env)
expect(headers['Set-Cookie']).to match('old_context')
end |
(See #159 if you'd like to simply extend the cookie's max-age or drop it entirely.) |
Should be replaced by this one: #194 |
No description provided.