Open mp911de opened 8 years ago
This is somewhat by design. The reason is we need to request an OAuth access token scopes and there are lot more scopes for administrative users (we don't want to request the additional scopes for non admin users).
When the access denied exception happens, it should be handled by attempting to re-authenticate as an administrative user and obtain an access token with the additional scopes required. Is this not happening? It works for me.
NOTE: We could change the updated scopes of the access token logic to be distinct from being an admin user. I believe this would be a large improvement. However, this would be quite a bit of work.
Turns out I used /manage/
as URL instead of the correct /admin/
URL. Somewhat fooled myself because I received a basic auth prompt.
@mp911de Thanks for the response. You are right that the /manage/
URL could be configured better (i.e. use the same Security configuration as the rest of the application). That would be another nice improvement.
Could it maybe also be made configurable what the admin email domain must be?
That's what I bumped into :sweat_smile:
Also, the GitHub team id is also hard coded (for the CLA_AUTHOR
permission.
@Shredder121 Yes that could be made configurable. If you would like to send a PR, please do (just please make the defaults what we are using now).
That's what I've seen as well but I didn't want to dig into other tickets atm. Sounds like a good addition for something like OrganizationProperties
providing some defaults
The
admin
andclaAuthor
flags are not set if a user logs into the application and then decides to perform administrative tasks. This results in access denied when accessing resources protected by admin/CLA author roles.