Hi team,
I’m setting up Gitlab login for self-hosted Taiga. Following the guidelines, I need to first create a Gitlab application with id and secret to fill in GITLAB_API_CLIENT_ID and GITLAB_API_CLIENT_SECRET accordingly in docker-composel.yml . But I cannot figure out the redirect-url for the application which is a must for Gitlab to create the application.
Say my instance is hosted at https://my-taiga.io:9000. Could you please help me find out the redirect url for Gitlab?
Thank you!
p.s. From my experience with other products using Gitlab login, the redirect url seems to have an instance id inside, like (for example) https://my-taiga.io:9000/login/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/callback. If so, how should I find out the instance id?
Below is a screenshot of my Gitlab “create application” page.
It should be <your_taiga_instance_address>/login. So, in your case, it’s
https://my-taiga.io:9000/login
Best regards
It seems to work! Thank you for the timely help!
However, when I come back to Taiga from the Gitlab login page, Taiga complains Oops, something went wrong... and I cannot log in. The next line in the red bar says
Out Oompa Loompas have not been able to get you credentials from GitLab.
I got stuck because I had only limited ways to debug. From the docker compose logs, I found a 500 error with taiga-gateway. The error message was like
<intranet-ip-addr> - - [09/Jul/2023:13:50:31 +0000] "POST /api/v1/auth HTTP/1.0" 500 141 "https://my-taiga.io:9000/login?code=da797551e40acc02045632f56f05599c0df99d64b3592f52f8958f058d3bc356&state=gitlab" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.67" "<internet-ip-addr>"
Could it be because I hosted the Taiga instance behind an SSL nginx proxy?
If so, I would like post my nginx config within another topic.
Thanks!
I don’t think it has anything to do with ssl certificates. It may be a configuration problem in the backend (taiga-back) because it is not being able to connect to Gitlab.
Maybe you can find more info about the error with docker compose logs taiga-back before login.
Check your docker-compose.yml file and add all the settings needed in each section:
Add to &default-back-environment environments
ENABLE_GITLAB_AUTH: "True"
GITLAB_API_CLIENT_ID: "gitlab-client-id"
GITLAB_API_CLIENT_SECRET: "gitlab-client-secret"
GITLAB_URL: "gitlab-url"
PUBLIC_REGISTER_ENABLED: "True"
Add to taiga-front service environments
ENABLE_GITLAB_AUTH: "true"
GITLAB_CLIENT_ID: "gitlab-client-id"
GITLAB_URL: "gitlab-url"
PUBLIC_REGISTER_ENABLED: "true"
Hi David,
After some trail n error I found something which seems to be the cause:
(I’m hosting Gitlab v16.1 as a docker container)
The failed request POST /api/v1/auth seems to call /api/v3/user of Gitlab api, while I found in Gitlab’s doc that the only supported version is 4 as noted here. So I suppose there could be an update for the Gitlab auth connector.
If this is the case please let me know. Thanks!
Below is the code from taiga-contrib-gitlab-auth repo
Yes, v3 was deprecated in 2018. You define the URL of your instance in docker-compose.yml with the variable GITLAB_URL. What value are you using for it?
Hi!
My Gitlab (v16.1.1) is accessible from https://sdird.com:8000, so I think GITLAB_URL=https://sdird.com:8000. Is it correct?
I mean with the code in taiga-contrib-gitlab-auth, after the login the taiga-backend seems to call https://sdird.com:8000/api/v3/user while it should be https://sdird.com:8000/api/v4/user. – Are we acutally using taiga-contrib-gitlab-auth to login in via Gitlab?
Sorry, I found the error. We have to upgrade the plugin to make it compatible with the new API. However, I don’t understand how tree.taiga.io keeps working, using the Gitlab’s SaaS.
I have created an issue to solve it Taiga
Glad to see your reply, much appreciated. Thank you!
1 Like
Hi David,
Do we have any updates for now? I’m afraid that my team has been blocked from using Taiga due to the login issue. Could you please prioritize this task? Or do we have any other ways to work around the problem?
Hi @pkubangbang
The situation has not changed much since my last comment. The team is focused on the development of Taiga Next and our dedication (to Taiga 6.x) is limited. As workaround, users can use the same email they use in gitlab so that when the problem is fixed, the accounts will be joined after gitlab plugin activation.
I hope we can release a new version of the plugin soon.
