QA (public) » openQA Project (public)

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?

looks good :+1:

The main feature was merged. https://github.com/os-autoinst/openQA/pull/3757 But i do still want to add documentation and clean up the whole authentication code a little (as was suggested by reviewers).

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?

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.