coordination #58184: [saga][epic][use case] full version control awareness within openQA, e.g. user forks and branches, fully versioned test schedules and configuration settings
See parent epic #86063
- AC1: openQA jobs can be triggered with single curl calls
- AC2: non-operator users are prevented from triggering jobs or do not even see the functionality
- e.g. a POST route where one can authenticate with username+password forwarded to any external authentication service or existing API key+secret.
#1 Updated by kraih about 1 year ago
- Assignee set to kraih
I can take a look at this. AC1 could use some clarification though. Do we want a workflow with pre-negotiated authentication tokens (stored in the database, think GitHub personal access tokens), or a workflow where an expiring token can be requested via the API itself (since it expires, most curl operations would require at least two HTTP requests, one to authenticate and another to actually perform the API operation, not to mention browser requirements for external authentication methods like OpenID)?
#3 Updated by cdywan about 1 year ago
Personally, i always liked the simplicity of GitHub personal access tokens. It makes using curl for API access very comfortable. But of course there's a security risk with tokens that require the user to press a delete button and that never expire on their own.
We could probably still decide to revoke tokens at an expiry date if we want to. But it's worth considering that expiry of API keys for openQA is already optional... maybe we should just get rid of that?
And GitHub allows you to define the permissions granted when using the token. So you could for example allow jobs to be cloned but nothing else.
- Status changed from Workable to In Progress
We already have expiration on API keys+secrets. Can we just use the already existing keys+secrets?
We can, and for starters i'll make a version that works like
curl -u kraih:KEY:SECRET https://openqa.opensuse.org/....
Opened a PR with the fix. https://github.com/os-autoinst/openQA/pull/3774
Problem was that my local and staging machine tests did not involve users created via OpenID/OAuth2. So the
username field was never different from the
nickname field, which is usually the case in production.
- Subject changed from openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+) to openQA jobs can be triggered with single curl calls
Renaming this as per what was discussed and done here, see #90788 for the web UI counterpart.