-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
PATCH OAuth 2.0 Client overwrites client_secret #2869
Comments
Thank you for the report! My hunch says that we're re-hashing the hash which was set before. Most likely because are fetching the client from the store Line 188 in 31af257
but are not nulling the secret but instead just apply the patch on it. Compare this to the PUT method Line 147 in 31af257
which receives the full payload from the caller, thus not having the hashed password available. Would be awesome if you could supply a patch/PR with a failing test case! |
Hey @aeneasr, thanks for the reply! I can submit the failing test case. Would you be able to point out some other test examples where I can base this from? |
This was pretty straightforward to fix. Much like you've mentioned, nulling the secret if it hasn't changed does the trick. I have also added a test case that captures the failure and now it is all green. |
Preflight checklist
Describe the bug
A
PATCH
request against$hydra_uri/clients/$client_id
causes Hydra to overwrite theclient_secret
even if not explicitly specified.Issue a
PATCH
request to updatescope
:Note the
client_secret
is returned (not in cleartext) and it matches the one in the database.Check database again and
client_secret
has been modified:If I
PATCH
theclient_secret
field updating the secret, it is returned in the response in cleartext as documented:Reproducing the bug
PATCH
OAuth 2.0 Client without passingclient_secret
Relevant log output
Relevant configuration
No response
Version
1.10.6, 1.10.7
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Kubernetes with Helm
Additional Context
According to the docs this is a bug:
The text was updated successfully, but these errors were encountered: