Closed chrisa closed 12 years ago
do you happen to have a testcase for this?
On Wed, Feb 1, 2012 at 5:16 AM, Chris Andrews < reply@reply.github.com
wrote:
I've noticed that in the production environment, or specifically, with "config.cache_classes = true" set, tokens are not expired properly. I've tested this with Rails 3.1.3 and devise_oauth2_providable 1.0.5.
This seems to be a problem in Devise::Oauth2Providable::ExpirableToken#expires_according_to, where the use of a named scope with a lambda that's then applied using default_scope causes the lambda to be evaulated only once, at server start. That then means that tokens are checked for expiry against the server start time, not against the current time, which means they'll never expire - at least until the server is restarted.
The simplest fix appears to be to pass the lambda directly to default_scope, which does then cause it to be re-evaluated for each load. I couldn't find anywhere that appears to depend on the existence of the named scope itself.
Reply to this email directly or view it on GitHub: https://github.com/socialcast/devise_oauth2_providable/issues/29
I don't I'm afraid - I've not been able to get the testsuite to run correctly, so I'd not started on a test. Are a number of failures currently expected?
I've noticed that in the production environment, or specifically, with "config.cache_classes = true" set, tokens are not expired properly. I've tested this with Rails 3.1.3 and devise_oauth2_providable 1.0.5.
This seems to be a problem in Devise::Oauth2Providable::ExpirableToken#expires_according_to, where the use of a named scope with a lambda that's then applied using default_scope causes the lambda to be evaulated only once, at server start. That then means that tokens are checked for expiry against the server start time, not against the current time, which means they'll never expire - at least until the server is restarted.
The simplest fix appears to be to pass the lambda directly to default_scope, which does then cause it to be re-evaluated for each load. I couldn't find anywhere that appears to depend on the existence of the named scope itself.