Document GitLab's required scope if using allowed_gitlab_groups or not
See original GitHub issueGitLabOAuthenticator is making some checks against GitLab’s REST API following a user has authenticated, in order to decide if the user is authorized. These requests against the GitLab REST API that follows authentication, are made with the access token that resulted from the authentication process.
This access token can get various degrees of permissions, which is influenced by the requested scopes, and will be seen by the user during the authentication phase. This issue is about these scopes, and that we need to request too powerful permissions through them, just because we maybe want to authorize the user because it belongs to a specific group in gitlab with certain status in this group.
Here are some of the scopes with GitLab specific meaning we can make use of.
AH! I notice now that we can make use of read_api
instead of api
which is just the way too powerful option! It would be great to reduce it even further to something like read_groups
or similarly, but this is far much better than write. Okay!
Action points to close issue
- Update documentation to clarify what scope is needed if we are using and if we are not using the allowed_gitlab_groups configuration, it will be different because only if we configure that do we end up needing to make certain REST API requests to GitLab (as seen here).
Related
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (6 by maintainers)
I’ve found it.
This:
Should be THIS:
Indentation means you don’t set it inside the auth type definition, you set it globally 🤦♂️
Not sure if this is documented specifically this way. I’ll double-check.
No problem, I was merely trying to keep it on-topic of gitlab, scope and documentation because if this is how it should work via Helm… Right now i’ve not seen it working yet so wanted to make sure the docs are right 😃
Let me double-check everything and get back to you!