Official Changes to GitLab authentication flow

With the release of GitLab 15.0, some of our users have noticed an increase in authentication issues when using OAuth. This is related to the move from un-expiring access tokens to tokens that expire within two hours of creation. We are currently working on adding support for GitLab personal access tokens (PAT) which provides support for both tokens without an expiration date and users that have enabled two-factor authentication.

We understand that CI/CD is an integral part of the development experience, and having to continue to re-authenticate is not ideal. While we are working on support for PATs, we will disable the use of GitLab OAuth. If you are currently using SSH, then there is no change required by you. If you are currently using OAuth, no action needs to be taken until your credentials expire. Once your credentials expire, instead of authenticating with GitLab, you will be instructed to add an SSH Key to your account.

When support for Personal Access Tokens is added to our dashboard, we will be sure to notify users via an update to this forum post.

The following is an example of transitioning a project from OAuth to SSH.

Transitioning from OAuth to SSH
The config page should show GitLab as the OAuth provider when configured with OAuth.




On the config page, click the button under Source Control Settings labeled “Show SSH Key”.

Copy the contents in the modal. It should start with “ssh-rsa”.

Head over to your GitLab project and log into the account to which you wish to add the SSH Key.

Once you are logged in, click on the user icon in the top right corner and select “Preferences”.




You should see an option for SSH Keys in the left-hand navigation menu. After navigating to the SSH Keys screen, you should see a page like the following.




Paste the copied key into the Key box, add a title, and set an expiration date optionally. If you configure an expiration date, you will need to re-add the SSH key at that point in the future. Leaving the date blank will not expire the SSH Key.


Once you have completed the form, click the “Add Key” button. You will be presented with a page confirming that the SSH Key was added.



Now go to your GitLab repo and copy the link to the repository. You can grab this from your browser’s address bar or the clone drop-down on your repo page.



OR




With your repo URL copied, head back over to the UCB Config page for your project.

Click on “Edit Source Control”. You should then see,




Select the “GitLab” icon. This will transition you to the manual tab with “GIT” selected as the SCM Type. Paste your repo URL into the field and click the “Next: Access” button




The page will show processing and then, assuming the SSH Key was added to the user correctly, transition back to the config page.




The source control settings should now reflect the “Access” as “SSH Key”




Troubleshooting

Repo is not accessible error.



This error is related to the inability to access your project with the SSH Key provided. Try the following:

• Validate the SSH Key was added to a user with access to the repo.
• Try deleting the SSH Key from your GitLab account and adding it again.
• If you configured the key as a GPG or Deploy key, try moving it to a user with access to the repo.
• Validate the link to your repo. Try editing the URL and pasting the value from the “SSH” option in the clone drop-down on GitLab.
• If none of the above work, please contact the UCB Support Team.

Clone Hangs when Using Submodules
If your project is configured to use submodules and the clone step is hanging, verify that your submodules are configured to use either the relative path or the SSH path to the submodule. This stack overflow post has an excellent example of using relative paths. https://stackoverflow.com/a/44630028