-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Device Code Grant] Submitting the same user code more than once results in internal server error #1894
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
Thanks for the report, @moscicky!
I agree, this seems like the most reasonable fix here.
Thanks. I agree. I'll also review the spec and existing implementation first to make sure it's consistent. |
Hi @sjohnr, do you know if a fix is coming soon for this issue? |
@antoinelauzon-bell thanks for the ping. I think I lost track of this issue. I will see if a fix can be made shortly. |
Related gh-1977 |
Fixes spring-projectsgh-1894 and spring-projectsgh-1977 Signed-off-by: [email protected]
Fixes spring-projectsgh-1894 and spring-projectsgh-1977 Signed-off-by: [email protected]
Fixes spring-projectsgh-1894 and spring-projectsgh-1977 Signed-off-by: [email protected]
Fixes spring-projectsgh-1894 and spring-projectsgh-1977 Signed-off-by: Antoine Lauzon <[email protected]>
Fixes spring-projectsgh-1894 and spring-projectsgh-1977 Signed-off-by: Antoine Lauzon <[email protected]>
This is now resolved via gh-1997 |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
[Device Code Grant] Submitting the same user code more than once results in internal server error cause by NPE
To Reproduce
activate
and copy the user codeThis is because there is an NPE in
OAuth2DeviceVerificationAuthenticationProvider
.OAuth2DeviceVerificationAuthenticationProvider
assumes thatSCOPE
attribute will not be null when user verifies the device butSCOPE
attribute is removed during the first verification.This NPE can be probably fixed by checking early whether the user code has been previously invalidated.
Expected behavior
RFC does not mandate what should happen in this situation but I believe 4xx error would be more appropriate
The text was updated successfully, but these errors were encountered: