-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
I was also surprised... |
Any updates on this? |
Not sure. I ran into this issue repeatedly when using arc commander on a fresh machine, recently. |
Maybe this is an issue of the lifetime of the token. I think it's set to just 2 hours or something. @j-bauer? |
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: There it is stated, that we should use the refresh token to retrieve a new access token after it expired: 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. |
Maybe this is also of help/interest to you guys: Here are the logs:
|
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. |
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.
The text was updated successfully, but these errors were encountered: