search

nfdi4plants / ARCCommander

Tool to manage your ARCs
MIT License
11 stars 9 forks source link

[BUG] access token needs to be stored again #193

Open Brilator opened 1 year ago

Brilator commented 1 year ago

User feedback from yesterday's hands-on workshop: apparently, the arc remote accesstoken get ... needs to be repeated, if one uses a different network / wifi.

I was unable to reproduce this error, but multiple users had to redo this step although the computer was already token authorized.

HLWeil commented 1 year ago

Hey @Brilator,

to my understanding, the token stored should not be dependent on the network. @j-bauer, any idea what might be the issue behind this?

Brilator commented 1 year ago

I was also surprised...

HLWeil commented 1 year ago

Any updates on this? I don't think that this is something the ArcCommander can fix, so I would close this issue.

Brilator commented 1 year ago

Not sure. I ran into this issue repeatedly when using arc commander on a fresh machine, recently. Can close for now, but might have to re-open with the next workshop series.

HLWeil commented 1 year ago

Maybe this is an issue of the lifetime of the token. I think it's set to just 2 hours or something. @j-bauer?

j-bauer commented 8 months ago

I will try to reproduce the issue but can you give me some information on how the problem arises? Or just a timestamp when it happened to look at the logfiles in that time range. Just get a token from the ARC commander and try to use it x minutes later until the unauthorized errors appear?

The issue is most likely related to the lifetime of the token issued by GitLab, not the token issued by Keycloak. The ARCC requests a token from GitLab directly. The user is then redirected to Keycloak to login but that is only for GitLab to authenticate the user. When that is done, GitLab issues the token itself and does not forward/re-use the Keycloak token. In other words, the Keycloak lifetime configuration does not impact the lifetime of the GitLab token directly. There is no configuration parameter to configure the lifetime of the GItLab token as far as I can see in the documentation. However, the usual mechanism in oAuth/OIDC is the use of refresh tokens, which seems to be the recommended way to handle this particular problem:

Here is the relevant part from the documentation about expiring tokens: https://docs.gitlab.com/ee/integration/oauth_provider.html#access-token-expiration

There it is stated, that we should use the refresh token to retrieve a new access token after it expired: https://docs.gitlab.com/ee/api/oauth2.html#authorization-code-flow (3. bullet point).

That should be the approach to aim for. @HLWeil we can do a live coding session where we tackle that problem? It shouldn't be too hard to implement in the ARC Commander.

ZimmerD commented 8 months ago

Maybe this is also of help/interest to you guys: I recently tried to sync an local arc with the datahub. I retrieved my accesstoken using Arc Commander version 0.5.0 via arc remote token get, and initiated the push via arc sync. The upload failed, I assume that my token also expired before the task finished.

Here are the logs:

2023-11-22 18:00:12.0406 GitSyncLog TRACE: Push
2023-11-22 18:00:12.0406 ExecuteGitCommandLog TRACE: Run git push -u origin main
2023-11-22 18:00:14.1916 ExecuteGitCommandLog INFO: GIT: warning: redirecting to https://git.nfdi4plants.org/zimmer/NMJ.git/
2023-11-22 18:00:18.3712 ExecuteGitCommandLog INFO: GIT: Locking support detected on remote "origin". Consider enabling it with:
2023-11-22 18:00:18.3712 ExecuteGitCommandLog INFO: GIT:   $ git config lfs.https://git.nfdi4plants.org/zimmer/NMJ.git/info/lfs.locksverify true
2023-11-23 08:44:45.1594 ExecuteGitCommandLog ERROR: GIT: fatal: helper error (-1): User cancelled dialog.
2023-11-23 08:44:45.1897 ExecuteGitCommandLog INFO: GIT: bash: line 1: /dev/tty: No such device or address
2023-11-23 08:44:45.1897 ExecuteGitCommandLog ERROR: GIT: error: failed to execute prompt script (exit code 1)
2023-11-23 08:44:45.1897 ExecuteGitCommandLog ERROR: GIT: fatal: could not read Username for 'https://git.nfdi4plants.org': No such file or directory
2023-11-23 08:44:45.1897 ExecuteGitCommandLog INFO: GIT: Uploading LFS objects:  99% (159/160), 1.2 GB | 176 KB/s, done.
2023-11-23 08:44:45.1897 ExecuteGitCommandLog INFO: GIT: batch response: Git credentials for https://git.nfdi4plants.org/zimmer/NMJ not found.
2023-11-23 08:44:45.2023 ExecuteGitCommandLog ERROR: GIT: error: failed to push some refs to 'https://git.nfdi4plants.org/zimmer/NMJ'
2023-11-23 08:44:45.2023 ProcessCommandLog INFO: Done processing command.
j-bauer commented 8 months ago

Thanks @ZimmerD , that is indeed valuable information. It is most likely due to expiring access tokens as you hypothesized. With the timestamp, we can have a more detailed analysis of the logfiles to confirm that theory. I will update when we know more.