-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Authenticating an existing Warden/Devise User #200
Conversation
Fantastic PR @nickL. You just made my day with these tests.
I have been getting asked this a lot. I don't remember exactly what the incompatibility is, but I do remember that I had to change some things for Rails 4.2. I'll downgrade to Rails 4.1 and see if the tests still pass. Is there a way to have the test suite run against multiple versions of Rails? |
Authenticating an existing Warden/Devise User
Thanks nickL for your work. I encounter two problems with the solution:
if never true because I am logged in with devise_token_auth and so my token is set.
@token will be nil but it is still included in the header (as access-token)
because he is trying the do nil.split("\n").join(", ") because access-token is nil. Let me know. Thanks a lot. |
Actually there are many more problems:
in the destroy method of the session controller. (Just like you called the sign_in method in the create method) If you have an user with a tokens empty.
than you will get this stack
the code responsible for this error is :
You are trying to build_auth_header but you are actually still connected with warden so @token is nil |
Hi @casertap, I'm sorry you're running into such trouble! I'm not familiar with the error you describe re: warden/devise_token_auth and I'm having trouble reproducing. Though I'll do my best to help if I can. To get me started can you do either of the following to help me reproduce?
1 or 2 would be preferred, it'll help me try and reproduce this in the way you described. Happy to help if I can. Thanks! |
there's a few PRs that have just gone in, so any work you might make against this issue, be sure to do so on a fresh pull of master. for instance, |
@casertap @nickL I'm running to what sounds like kind of a similar issue to @casertap, but I don't understand how. We set the Yet, once every few days, we run into a state where a request comes in with no tokens, and the user is still found by: It's a long story about how we noticed this. I don't think it's causing us any direct problems, but it makes me nervous that I don't really understand what "logged in" really means on my site right now. I can reproduce this issue by logging in and then deleting my local storage in the Chrome dev tools. This makes sense because, in that case, I still have a session_id stored in a cookie, so the next request sends up a session_id but no token. However, I do not believe that my real uses are out there deleting local storage values but not deleting cookies. Before #251, this would happen after an explicit logout, since the logout removed the token from the auth headers but did not remove the session_id from the cookie, but #251 solved that. So now I don't know how it's happening. Do you have any other explanation of how someone could get into this state where they send up no token but still get logged in via warden? |
@nickL / @casertap - Due to the issues resulting from this warden implementation, I'm inclined to make this warden lookup configurable under some sort of |
@nbrustein @booleanbetrayal - I'm running into the same issue as @casertap ,
Please advise if there are workarounds or patches for this issue. We need the sessions enabled for omniauth login. Thanks a lot for your help and a great gem. |
@booleanbetrayal , @casertap : Sorry!! I missed the notifications on this thread and just saw your replies. My mistake for not replying sooner. @booleanbetrayal : I like the idea of making this configurable I don't think it's a use-case for everyone as soome implementations may not use warden this way. I'd support a configurable toggle if that would be sufficient. I don't mind helping with this if you want to talk through it. |
@lynndylanhurley - we're seeing the |
@booleanbetrayal - That's what I was afraid of. This line seems to be the real problem: devise_warden_user = warden.user(rc.to_s.underscore.to_sym) I think it was intended to pull the data from an existing devise session (standard devise, not devise_token_auth), but it seems to be also instructing the browser to set a cookie containing the user's devise session info. This is problematic because the API shouldn't deal with cookies at all (that is the purpose of token based authentication). But I understand why this functionality is useful. So the question is, can we accomplish what this line of code is doing (identifying the user from the standard devise session) without actually setting the cookie? |
@lynndylanhurley - i dunno ... i was toying with ripping that support out entirely or at the very least make it opt-in. here's how @nbrustein and I are dealing with it today. it's a hacky hodge-podge of application_controller.rb rescue_from NoMethodError, with: :catch_devise_error
def capture_devise_no_method_error(exception)
if exception.message == "undefined method `[]' for nil:NilClass" &&
exception.backtrace[0].match(/build_auth_header/)
# log the exception, etc etc ...
reset_session
return true
else
return false
end
end home_controller.rbbefore_action :reset_session # NOTE: this is a little misleading. the session is only used briefly and only during omniauth (?). devise_token_auth.rb (monkey-patch)require 'devise_token_auth/sessions_controller'
module DeviseTokenAuth
class SessionsController < DeviseTokenAuth::ApplicationController
after_action :reset_session, :only => [:destroy]
end
end |
This would be easier if we had a failing test that we could solve against. I'll see what I can come up with tonight. |
@booleanbetrayal - can you please try version |
@lynndylanhurley - I'm still experiencing the same issue as when you were explicitly calling Can is wired up via a https://github.com/ryanb/cancan/blob/master/lib/cancan/controller_additions.rb#L357 "/Users/brent/.rvm/gems/ruby-2.2.2@back_royal/gems/cancan-1.6.10/lib/cancan/controller_additions.rb:357:in `new'",
"/Users/brent/.rvm/gems/ruby-2.2.2@back_royal/gems/cancan-1.6.10/lib/cancan/controller_additions.rb:357:in `current_ability'",
"/Users/brent/.rvm/gems/ruby-2.2.2@back_royal/gems/cancan-1.6.10/lib/cancan/controller_additions.rb:338:in `authorize!'",
"/Users/brent/.rvm/gems/ruby-2.2.2@back_royal/gems/cancan-1.6.10/lib/cancan/controller_resource.rb:41:in `authorize_resource'",
"/Users/brent/.rvm/gems/ruby-2.2.2@back_royal/gems/cancan-1.6.10/lib/cancan/controller_resource.rb:10:in `block in add_before_filter'",
... |
@booleanbetrayal - |
@lynndylanhurley - I'm always seeing |
Agreed. I was at this all night last night, and I'm still not sure how to write a test for this 😵 I'm speculating here, but it looks like Devise/warden is getting the browser to set a cookie that correlates to some kind of warden session. That session is actually destroyed on the server when the The only way I could find around this was to prevent the creation of that cookie. It would be better to have the browser terminate the cookie upon logout. I'll keep looking for a way to do that. |
@lynndylanhurley - going to pick this up (configuration flag / new default) unless you've already started it |
@booleanbetrayal - please do. I'll keep trying to figure out why the session persists after logout, and if there's anything that can be done to prevent it. |
@lynndylanhurley - maybe take a quick peek at #428 and let me know if you see anything off |
This is now configurable as per #428 - defaulting to disabled |
I keep getting this error seems like it comes from this PR on this line: I'm getting this:
|
Yo!
Alright, so I think this will help with #120, #168, & #196; In the event an app uses devise for normal session authentication and would like to also authenticate users via
DeviseTokenAuth
then I think this will help support both strategies and ease the transition. Small bit of interstitial code to check for the user in warden and, if they're missing authentication details, create a token for them and pass them through. Otherwise, the normal token auth strategy kicks in.I had a couple of questions that are worth mentioning before merging this in, if it feels like its on the right approach:
DemoUserController
integration test. Does that feel like a good place for it?