Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Brilator opened this issue Jun 1, 2023 · 8 comments
Open

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

Brilator opened this issue Jun 1, 2023 · 8 comments
Labels
Type: Bug Something is not working, and it is confirmed by maintainers to be a bug.

Comments

@Brilator
Copy link
Member

Brilator commented Jun 1, 2023

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
Copy link
Member

HLWeil commented Jun 2, 2023

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
Copy link
Member Author

Brilator commented Jun 2, 2023

I was also surprised...

@HLWeil
Copy link
Member

HLWeil commented Jul 20, 2023

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

@Brilator
Copy link
Member Author

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
Copy link
Member

HLWeil commented Jul 20, 2023

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
Copy link

j-bauer commented Nov 10, 2023

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
Copy link

ZimmerD commented Nov 24, 2023

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
Copy link

j-bauer commented Nov 24, 2023

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.

@omaus omaus added the Type: Bug Something is not working, and it is confirmed by maintainers to be a bug. label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something is not working, and it is confirmed by maintainers to be a bug.
Projects
Status: No status
Development

No branches or pull requests

5 participants