Open ssssam opened 1 month ago
https://openqa.debian.net/ authenticates using gitlab. Can you check why that works for Debian but not for you?
Sure. I guess Phil Hands is the person to speak to.
The currently working config snippet from openqa.debian.net's /etc/openqa/openqa.ini
is:
## Authentication method to use for user management
[auth]
# method = Fake|OpenID|OAuth2
method = OAuth2
#for salsa.debian.org one can use:
[oauth2]
provider = debian_salsa
key = ...
secret = ...
which relies on the presence of this change, which has since been merged upstream.
Note that there is also this comment in openqa.ini
, which is based on what I used to do before I patched the mojo plugin to know about debian_salsa
as a provider, so should demonstrate how to point things at some other gitlab instance:
# alternatively, one can specify parameters manually without relying on magic a provider name:
#[oauth2]
#provider = custom
#unique_name = debian_salsa
#key = ...
#secret = ...
#authorize_url = https://salsa.debian.org/oauth/authorize?response_type=code
#token_url = https://salsa.debian.org/oauth/token
#user_url = https://salsa.debian.org/api/v4/user
#token_scope = read_user
#token_label = Bearer
#nickname_from = username
Currently openQA can't handle the OAuth user info returned from GitLab.
GitLab returns the user id in a field named
sub
, while openQA expects it to be in a field namedid
.GitLab is complying with the OpenID Connect core 1.0 spec, see: section 5.1. So it looks like openQA should perhaps accept
sub
as an alternative toid
.GitLab docs: https://docs.gitlab.com/ee/integration/openid_connect_provider.html