Skip to content
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

[Bug] RolesRequiredHttpContextExtensions.ValidateAppRole will only check first role claim and fail when there are many role claims #374

Closed
adriannasui opened this issue Jul 28, 2020 · 5 comments
Assignees
Labels
bug Something isn't working fixed P1
Milestone

Comments

@adriannasui
Copy link

Hi, I encountered an issue on version 0.2.1-preview where calling ValidateAppRole will not work as expected.

Issue happens when i call ValidateAppRole and my access token has a 'roles' claim containing an array of roles. Somwhow, my 'roles' claim gets transformed into multiple 'role' claims in context.HttpContext.User. And the code inside ValidateAppRole is not properly written to handle this scenario, it only looks at the first 'role' claim and my call fails with 403.

This is the line where I found the issue.

rolesClaim = context.User.FindFirst(ClaimConstants.Role);

This code will incorrectly stop on the first role claim.

Please let me know it any more info is needed, I could even do a PR to solve this, I will do a quick custom implementation of ValidateAppRole just to move on with my project.
Thanks

@adriannasui adriannasui changed the title RolesRequiredHttpContextExtensions.ValidateAppRole will only check first role claim and fail when there are many role claims [Bug] RolesRequiredHttpContextExtensions.ValidateAppRole will only check first role claim and fail when there are many role claims Jul 28, 2020
@jmprieur jmprieur added bug Something isn't working P1 labels Jul 28, 2020
@jennyf19
Copy link
Collaborator

@adriannasui thanks you. we definitely welcome outside contributions, so feel free to propose a PR.

@jmprieur jmprieur added this to the [3] Fundamentals milestone Jul 30, 2020
@jennyf19 jennyf19 self-assigned this Aug 1, 2020
@jennyf19 jennyf19 mentioned this issue Aug 1, 2020
@jennyf19
Copy link
Collaborator

jennyf19 commented Aug 1, 2020

@adriannasui We are thinking of throwing now if the roles do not match, verses returning to the controller, because the controller could continue to do things it shouldn't at that point. We are still looking at the user experience here, but if you have thoughts on this, let us know. Changes are in this branch. thank you.

@adriannasui
Copy link
Author

sorry about not answering, seems my github notifications are not properly setup on my part.
About throwing I suspect for the caller it looks like a 403 (Forbidden) with a custom message in both cases (throw vs no throw).
Throwing seems safer to me, it conveys the fact that stopping at this point is mandatory due to authorization issues.
Was looking at your code and it looks fine, a bit slimmer than my implementation, so I do not plan on doing a PR at this point.
Thanks
Adrian

@jennyf19
Copy link
Collaborator

jennyf19 commented Aug 3, 2020

Thanks for the quick feedback @adriannasui ....we agree that throwing seems safer and less "magical"

@jennyf19
Copy link
Collaborator

jennyf19 commented Aug 7, 2020

Included in 0.2.2-preview release

@jennyf19 jennyf19 closed this as completed Aug 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed P1
Projects
None yet
Development

No branches or pull requests

3 participants