Nils Mosbach

If you're running devworkspace mode, which I think is the default in Che 7.42 Kubernetes api Server requires to validate against Keycloak. We had similar issues with Che 7.42. Since...

We're currently having issues with GitLabs token expiration time of 2 hours. Based on the Documentation of BitBucket, tokens might expire after 2 hours as well. See https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/#OAuthonBitbucketCloud-Refreshtokens I've created...

Generally you're right. GitLabs Access Tokens are quite "short-living". Most applications we have integrated with, use something from a couple of days to months, but still require tokens to get...

@mshaposhnik Simply restarting a workspace does not fix it. It looks like the authentication procedure is skipped in this case. Starting a new workspace works. This seems to update the...

@mshaposhnik Since GitLab has now removed the `Expire access tokens` setting, workaround is gone. Git credential secret-file is also mounted read only, which prevents users from making any change to...

changing `authorization_code_expires_in` in /config/initializers/doorkeeper.rb doesn't ssem to solve the issue.

> We have to decide when we are going to catch the event: on wokrspace start or / and during workspace runtime. From a user perspective I consider it mandatory...

From a users perspective PAT is a really nice option. For internal users, I find SSH a good option. If dealing with users outside of the organisation, starting a new...

I've tried patching the secret using kubectl in a developer container and that works for both (devworkspace-merged-git-credentials and git-credentials-secret-hifkp). I think we need to decide if using OAuth/PAT/https should be...

True. We could fetch new access tokens e.g. every 60'-90'. In this case tokens should get updated before they expire. At least for GitLab and Bitbucket that have a limit...