action #87698
closed
coordination #162539: [saga][epic] future ideas version for version control features within openQA
coordination #162554: [epic] Direct webUI support for job triggering
action #86063: [epic] Add possibility to trigger openQA API calls, e.g. single "jobs", without the need of the client / over the webUI / with curl
openQA jobs can be triggered with single curl calls
Added by okurz almost 4 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
Motivation¶
See parent epic #86063
Acceptance criteria¶
- 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
Suggestions¶
- e.g. a POST route where one can authenticate with username+password forwarded to any external authentication service or existing API key+secret.
Related issues
1 (1 open — 0 closed)
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)?
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.
kraih wrote:
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.
We already have expiration on API keys+secrets. Can we just use the already existing keys+secrets?
- Status changed from Workable to In Progress
okurz wrote:
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/....
- Status changed from In Progress to Feedback
Cleanups and documentation are done.
I tried curl -u okurz:$key:$secret -X POST https://openqa.opensuse.org/api/v1/jobs/1661550/restart now and I got "{"error":"invalid personal access token"}". Can you help?
- Status changed from Feedback to In Progress
kraih found the problem and will create a PR. o3 is hotpatched and I can confirm that the above works as expected.
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.
- Status changed from In Progress to Feedback
Everything looks good now.
- Status changed from Feedback to Resolved
- Copied to action #90788: openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+) added
- 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.
- Description updated (diff)
Also available in: Atom
PDF