Gitlab login: what is the redirect/callback url?

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.

The last released version (6.7.1) use the new Gitlab API endpoint.

1 Like

I got an invalid login type error. How to fix this.

Hi @Sridharan_g,

I’ve been able to register and log-in using the new Gitlab API version.

I’ll post here my local settings in case your invalid loging it’s due to a misconfiguration:

  1. Gitlab OAuth app settings:

  1. &default-back-environment added variables to the docker-compose.yml file:
  # ...your customizations go here
  PUBLIC_REGISTER_ENABLED: "True"
  ENABLE_GITLAB_AUTH: "True"
  GITLAB_API_CLIENT_ID: "2976863abd8793b12fa6e4df52dfeaa25a4ed1b4c504f05a946bf4aaaaaaaaaa"
  GITLAB_API_CLIENT_SECRET: "gloas-3f198bee3f8d163d12f724650cf8fe9f6e1fe370dd2af739c311ccaaaaaaaaaa"
  GITLAB_URL: "https://gitlab.com"
  PUBLIC_REGISTER_ENABLED: "True"
  1. &default-back-environment added variables to the docker-compose.yml file:
      PUBLIC_REGISTER_ENABLED: "true"
      ENABLE_GITLAB_AUTH: "true"
      GITLAB_CLIENT_ID: "2976863abd8793b12fa6e4df52dfeaa25a4ed1b4c504f05a946bf4aaaaaaaaaa"
      GITLAB_URL: "https://gitlab.com"
      PUBLIC_REGISTER_ENABLED: "true"

If you still cannot connect, having verified your settings are correct, please send us your payload data in the Developer Tools window and your docker console logs while you’re trying to log in:

 $ docker compose logs -f

Regards

Thank you for getting back to me. I have configured it as per your instructions.

Headers
The problem is a Bad gateway error
Request URL: https://taiga.test.live/api/v1/auth
Request Method: POST
Status Code: 400 Bad Request
Remote Address: 103.152.xxx.xx:443
Referrer Policy: strict-origin-when-cross-origin

Payload
{code: “a53f8232f3c968f8261dfca47a1da23d7d0448c0b3028dbd05c027189c5033b3”,…}
code: “a53f8232f3c968f8261dfca47a1da23d7d0448c0b3028dbd05c027189c5033b3”
redirectUri: “https://taiga.test.live/login
type: “gitlab”

I put SSL everything, but why is it showing my IP address with 443? Please suggest any other way to fix this.

My Payload

code: “11b4166b5e7fabc2d278e00d627246401bd4a5c4491fafc174295cf7b8279dda”
redirectUri: “https://taiga.test.live/login
type: “gitlab”

and I got a response like this
{
“_error_message”: “invalid login type”,
“_error_type”: “taiga.base.exceptions.BadRequest”
}

How to fix this please help.

There’s something I don’t get. Why do say it’s a “Bad gateway error” if the POST auth/v1/auth request returns a Status Code: 400 Bad Request.

I’m assuming you’ve set a secure https conexion in your .env file (TAIGA_SCHEME=https) and that’s why you’re seing the 443 port and you use https://taiga.test.live to access your installation.

Accordingly, you have to configure in gitlab a proper Callback URL with your https://taiga.test.live/login url.

Whit this, and the previous configration in the docker-compose.yml to activate and configure the gitlab pluging, you should be able to log in.

A bad gateway error would probably reflect an nginx problem.