Missing Auth Headers in Success Response

[ethagnawl]

I'm having an issue wherein the expected auth headers aren't being set, even though the request has been authenticated and there are no model validation errors (as reported in #884). I've determined the cause of the issue, but I'm not sure it's a bug. I wanted to open this issue to discuss potential workarounds or just note this behavior in case someone else runs into this in the future.

Roughly, here's what I'm seeing:

• I have a controller action (#show) which can be accessed by an admin or an end-user
• There are two before_actions which ensure that either an end-user or an admin is making the request. Handling this differently could potentially prevent the problem I'm reporting, so I'll include these below:

  before_action :authenticate_admin!, only: [:show, :update], if: -> { current_client.nil? }
  before_action :authenticate_client!, only: [:show, :update], if: -> { current_admin.nil? }

• I have a conditional inside #show (if admin_signed_in?) which checks to see if an admin is making the request - in which case it uses a different serializer to render the response.

The culprit seems to be the admin_signed_in? helper call, which ends up unsetting the response auth headers (because it eventually calls warden.authenticate). As I mentioned above, that behavior would make sense in isolation, so I'm not going to call this a bug. In a perfect world, there'd be some warning about what was happening or there'd be a non-destructive helper I could call to determine which user is making the authenticated request.

Environment:

• Ruby 2.4.2
• Rails 5.1.3
• Devise Token Auth 0.1.42
• Devise 4.3.0

[zachfeldman]

Thanks for reporting @ethagnawl . I'd definitely be down to include a warning at this stage!

[ethagnawl]

@zachfeldman Cool. I will have a look at the codebase to see if that's feasible.

Otherwise, are you aware of any workarounds? I realize I should create a separate AdminClients controller, but I was hoping to find a temporary solution.

UPDATE:

Removing the admin specific before_action and overriding authenticate_client! appears, thus far, to solve the problem.

def authenticate_client!
  return if admin_signed_in?
  super
end

(C/O this Stack Overflow answer.)

[zachfeldman]

Ha! Look at that. That's great. I think we should do a warning and a link to this issue if you have a moment. Otherwise we could close this.