User remains logged in when using devise and devise_token_auth in the same app

[fastjames]

I have read most of the submitted issues regarding the use of devise and devise_token_auth in the same Rails app, but I have not seen anyone describe the behavior that I am experiencing. I am attempting to do what seems pretty conventional (devise for desktop website auth, devise_token_auth for API namespace access), but I get a very unusual behavior on the mobile app. Here's a brief description of what happens:

1. Mobile app user signs in as User A
2. Mobile app user signs out as User A
3. Mobile app user signs in as User B
4. Mobile app user sees content specific to User A

The mobile app in question is written using ionic, and what I have seen is that devise appears to be establishing a login session for the mobile app user. When the mobile app user signs out (using the devise_token_auth action) the devise login session persists. This appears to override any subsequent logins, so that the user remains "logged in" as the original user. I thought I was pretty well-versed in wrecking sessions, but I have been unable to come up with a course of action that will log the user out.

My routes file is pretty conventional:

Rails.application.routes.draw do
  ActiveAdmin.routes(self)
  devise_for :users, controllers: { sessions: "users/sessions",
                                    registrations: "users/registrations" }
...
namespace :api do
  namespace :v2 do
      mount_devise_token_auth_for 'User', at: 'auth',
                                  controllers: {
                                    registrations: "api/v2/devise_custom/registrations",
                                    sessions: "api/v2/devise_custom/sessions"
                                  }

The controller overrides are in place to add attributes to the User model.

This seems like something that would happen in nearly every case where devise and devise_token_auth are used together, so I feel like I must be doing something wrong.

Solutions and workarounds

• Rails 4.2 seems to discourage disabling sessions per-controller, because "with lazy loading you won't need to do that."
• I tried using the logic from the devise sign_out action in an override for the devise_token_auth sessions/destroy action (https://gist.github.com/fastjames/8040ab97f1a2e3087b04). That did not seem to have an effect on the behavior of the site.
• My next idea is to add a call to the devise sign_out action in the mobile app itself.

Has anyone else observed this behavior? If so, how did you work around it?

[fastjames]

After experimenting with the last workound idea, I think I found part of the cause for the behavior I am seeing. When the mobile app calls DELETE /api/v2/auth/sign_out it does not appear to pass the session cookie in the request headers. That would certainly explain why none of my code changes in the destroy actions were having an effect on the session.

[fastjames]

Alright, I may have located the source of my problem. Looking at
https://github.com/lynndylanhurley/devise_token_auth#im-having-trouble-using-this-gem-alongside-activeadmin

It prescribes the use of DeviseTokenAuth::Concerns::SetUserByToken in your API base controller. As the name would imply, this sets the user based on the token passed in the request header. Unfortunately, this user gets set in the session. We do use ActiveAdmin but it's outside the scope of devise_token_auth so I don't think the suggestion applies to our app.

Would it be helpful if I attached a pull request with a doc update to that effect?

[fastjames]

Astute readers probably predicted the side-effect of my previous change: current_user is no longer available, so it is as if the user isn't logged in. Is there a way to include the SetUserByToken concern without having it set the user's session? Token authentication shouldn't need the session anyway, so I don't know why this happens at all.

[fastjames]

Thanks to a little more searching, I find that this issue was already covered and resolved in
#375

Sorry I didn't see it the (n-1)th time.

[fastjames]

I should also add that my testing method (login, logout, check another browser tab) does not work quite as expected with the beta release. The previous user remains logged in until the new user logs in.