lynndylanhurley / lynndylanhurley/devise_token_auth
Missing Auth Headers in Success Response
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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