clear session before Devise::Oauth2Providable::TokensController#create to work with iPhone #21

Open
wants to merge 3 commits into
from

Conversation

Projects
None yet
9 participants

atomgas added some commits Nov 12, 2011

add session.clear in a before_filter in Devise::Oauth2Providable::Tok…
…ensController

clear the session, so devise does not use session cookie based auth in any case
the iPhone SDK by default has a shared cookie jar for WebViews and NSURL Request's
and thus will send a cookie to this method
Contributor

wireframe commented Nov 15, 2011

I'd like to keep the devise_oauth2_providable gem as close to the official oauth2 spec as possible. since the spec does not allow for deletion of access tokens, i'd prefer that this functionality be moved to an unofficial gem extension.

@@ -1,4 +1,5 @@
class Devise::Oauth2Providable::TokensController < ApplicationController
+ before_filter :clear_session
before_filter :authenticate_user!
@wireframe

wireframe Nov 28, 2011

Contributor

would using force => true accomplish the same thing?

before_filter :authenticate_user!, :force => true

can you add a unit test to verify that either of these solutions work as expected?

@atomgas

atomgas Nov 28, 2011

will take a look at when i hvae time => wednesday ,

i dont think that

before_filter :authenticate_user!, :force => true

will work,
as I understand devise it will at first look for a session cookie and the
try strategies to authenticate the user, if the session is there devise will re-authenticate the user by the session cookie
or in depending of the ordering of the strategies

regards Luzifer

On Nov 28, 2011, at 6:39 PM, Ryan Sonnek wrote:

@@ -1,4 +1,5 @@
class Devise::Oauth2Providable::TokensController < ApplicationController

  • before_filter :clear_session
    before_filter :authenticate_user!

would using force => true accomplish the same thing?

before_filter :authenticate_user!, :force => true

can you add a unit test to verify that either of these solutions work as expected?


Reply to this email directly or view it on GitHub:
https://github.com/socialcast/devise_oauth2_providable/pull/21/files#r254799

Hello there,

In order to avoid this problem, I've found another workaround. I'm flushing my iOS cookies with the following snippet:

    NSHTTPCookie *cookie;
    NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
    for (cookie in [storage cookies]) {
        if ([[cookie domain] isEqualToString:@"yourdomain.com"]) {
            [storage deleteCookie:cookie];
        }
    }

Hope it'll help.
Regards,

mackross commented Dec 1, 2011

Also NSMutableURLRequest has a setHTTPShouldHandleCookies: method that allows you to turn off cookies for that request.

I think that the session.clear workaround is good to have, I'm experiencing the same exception, not on iOS but in a quick test I was writing.

If I instantiate a OAuth2::Client and attempt to get the token with the same auth code, it raises: http://pastie.org/private/nz3cas3aamm0vgcqizwpw

This is just a quick, unfinished test to evaluate devise_oauth2_providable vs doorkeeper. With the session.clear workaround I'm able to properly receive the error invalid_grant, otherwise 500. Using Capybara's reset! won't do anything.

Hello,
My opinion is that devise should ignore session cookies in this case.
session.clear workaround is not good because it makes user unauthorized (he should relogin).

I'm writing a chrome extension that will use OAuth2 as authorization layer.
This will lead to a scenario like this:

  1. open a chrome window (or tab, it's the same) and just login the rails application using user/password starting a new session.
  2. start an OAuth2 authorization "dance" through the developed extension (this means same cookies == "same session ID")

In this case with session.clear you will invalidate also the session at point 1, that is not what I would expect.
I think that just leaving cookies out of OAuth2 scope would do the job.

Am I missing something?

Thanks in advance

👍 needs fixed :)

I'm using this workaround for iOS AFNetworking library:

//
// AFNetworking subclasses ---------------------------------------------------------------------------------------------
//

@interface CTHTTPClient : AFHTTPClient
@end

@implementation CTHTTPClient

- (NSMutableURLRequest *)requestWithMethod:(NSString *)method path:(NSString *)path parameters:(NSDictionary *)parameters
{
    NSMutableURLRequest *req = [super requestWithMethod:method path:path parameters:parameters];
    [req setHTTPShouldHandleCookies:NO];
    return req;
}

@end


@interface CTOAuth2Client : AFOAuth2Client
@end

@implementation CTOAuth2Client

- (NSMutableURLRequest *)requestWithMethod:(NSString *)method path:(NSString *)path parameters:(NSDictionary *)parameters
{
    NSMutableURLRequest *req = [super requestWithMethod:method path:path parameters:parameters];
    [req setHTTPShouldHandleCookies:NO];
    return req;
}

@end

Here's how I worked around this issue using Rack middleware, which felt cleaner than hacking session.clear into
app/controllers/devise/oauth2_providable/tokens_controller.rb:

lib/cookie_filter.rb

class CookieFilter
  def initialize(app)
    @app = app
  end

  def call(env)
    if env['PATH_INFO'].match(/^\/oauth\/token/)
      env.delete "HTTP_COOKIE"
    end

    @app.call(env)
  end
end

Then I added this to config/application.rb:

require 'cookie_filter'
...
    # prevent cookies from screwing up devise_oauth2_providable
    config.middleware.insert_before ::ActionDispatch::Cookies, ::CookieFilter

raimo commented Aug 21, 2014

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment