-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
NoMethodError raised when fallback access token lookup fails #1224
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
Comments
Hi @JGrishey . Thanks for reporting this issue! I'll look at it a little bit later because I'm busy right now. /cc @oliverguenther |
I should include my implementation of
|
I think the issue lies here: doorkeeper/lib/doorkeeper/models/concerns/secret_storable.rb Lines 68 to 70 in 1599577
I can submit a PR with this code, if desired :) |
Thank you for finding Jacob, I have missed this. I'm on vacation without my
laptop at the moment so cannot provide a PR until second week of April, but
your observation is absolutely correct.
Am 26. März 2019 08:59:03 schrieb Jacob Grishey <[email protected]>:
… I think the issue lies here:
https://github.com/doorkeeper-gem/doorkeeper/blob/1599577d36e55494afb6046f3d4d7515077e1b3a/lib/doorkeeper/models/concerns/secret_storable.rb#L68-L70
#find_by will return nil, which sends nil into resource which gets sent
into #upgrade_fallback_value, causing the NoMethodError on #public_send
with :token=. There should probably be a guard clause here for the nil
value so that nil gets returned when there is no token found by the
fallback, which is indicated by the method's head comment:
upgrade_fallback_value resource, attr, plain_secret if resource
I can submit a PR with this code, if desired :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi @JGrishey . Feel free to send a PR :) |
Sure! I'll work on that today (hopefully!). |
Steps to reproduce
Create an application that uses access token hashing with an active hashing algorithm and a fallback hashing algorithm.
Expected behavior
In theory, the application should return a
401 Unauthorized
when making a request to a protected resource with an invalid access token.Actual behavior
Instead, the application returns a
500 Internal Server Error
when the fallback lookup fails. Here is the backtrace, which fails when trying to use#public_send
for:token=
:System configuration
Doorkeeper initializer:
Standard except for:
hash_token_secrets using: '::Doorkeeper::SecretStoring::Sha512Hash', fallback: '::Doorkeeper::SecretStoring::Sha256Hash'
Ruby version:
Ruby 2.4.5
This is in Doorkeeper version
5.1.0.rc2
The text was updated successfully, but these errors were encountered: