lynndylanhurley / lynndylanhurley/devise_token_auth

Missing Auth Headers in Success Response

Open
#1,019 3 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
3.6k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the controller action #show and the two authenticate_admin!/authenticate_client! before_actions described in the report. Trace the admin_signed_in? helper through warden.authenticate and inspect how that affects response auth headers. Done means determining whether the behavior is expected and identifying a documented workaround or non-destructive way to distinguish the authenticated user.

Written by the indexing model from the issue text.

Assessment

Tech stack
rails, ruby
Domain
api, authentication
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.