An error has occurred: The redirect URI included is not valid / window.setup_signup_team_page is not a function

[boer0924]

Installing GitLab from source, and Mattermost https://github.com/mattermost/platform/archive/release-1.4.zip install step by step followhttps://github.com/mattermost/platform/blob/master/doc/install/Production-RHEL6.md.

Integrations gitlab and mattermost follow https://github.com/mattermost/platform/blob/master/doc/integrations/Single-Sign-On/Gitlab.md

[boer0924]

Gitlab version 8.3.4 ,
The lastest stable version.

When i login with gitlab: An error has occurred: The redirect URI included is not valid.

Help me.

[boer0924]

The error logs snippet:

[2016/01/15 12:59:41 CST] [EROR] /api/v1/admin/log_client:client code=500 rid=3yzf619r4bnwzj3pgjj3b3wayy uid=s17rd488ppba9pwhkk8e9tw6ye ip=192.168.8.5 msg: Uncaught TypeError: Cannot read property 'name' of null row: 83 col: 64 stack: TypeError: Cannot read property 'name' of null url: http://mattermost.onenet.com/signup_team_confirm/?email=boer0924%40qq.com [details: ]
=====
/api/v1/admin/log_client:client code=500 rid=9ktkwsgu5bdt8gyhh1thgfrsyy uid= ip=192.168.8.6 msg: Uncaught TypeError: window.setup_signup_team_page is not a function row: 202 col: 8 stack: TypeError: window.setup_signup_team_page is not a function url: http://mattermost.onenet.com/ [details: ]

[it33]

Should be fixed in latest release, please let us know if it's not fixed?

[boer0924]

Still can't work! The version 1.4.0

gitlab version 8.3.4.

[jaijiv]

I started clean on my mac. After going to localhost:8065, see this similar error in logs which is causing sign up page to not show up.

/api/v1/admin/log_client:client code=500 rid=5mjdu6i4rpyimeh3yxg5qkti7r uid= ip=::1 msg: TypeError: window.setup_signup_team_page is not a function row: 233 col: 1 stack: TypeError: window.setup_signup_team_page is not a function url: http://localhost:8065/ [details: ]

Version: 1.4.0
Build Number: dev
Build Date: Sat Jan 23 18:21:15 UTC 2016
Build Hash: 1a0b123
Build Enterprise Ready: false

[it33]

Not able to repro this, please post to trouble shooting forum with information requested?

Others from the community may be able to help narrow this down,

[sinderrellar]

is this solved????

[marchoh]

I'm experiencing the same issue. I can't login with the Gitlab SSO.
This is because I use ssl (Apache as reverse proxy) and the redirect url uses just plain http.
In my apache config a have set "RequestHeader set X-Forwarded-Proto https", but Mattermost seems to ignore that, despite this code https://github.com/mattermost/platform/blob/35e3b8c40fcec5516f888ed5ba578e3a94f49257/api/context.go#L238.

To work around this I have set the redirect urls in Gitlab to http.
My apache will automatically redirect http to https.
But that doesn't change that the authorization process is still in plain text.

[it33]

Thanks to everyone for the follow-ups,

Closing this thread so we can move troubleshooting discussion into single thread on troubleshooting forum on window.setup_signup_team_page is not a function

[JJJ]

@marchoh is spot on here; the http vs. https issue appears to be a problem for us, too, but I think it's happening on the GitLab side vs. the Mattermost side.

In the screenshot below, note that the GitLab button provided by Mattermost is using the correct https URL:

GitLab, however, attempts to redirect back to http regardless of the Service URLs:

Here is the complete URL:

https://code.flox.io/oauth/authorize?response_type=code&client_id=*SNIPPED*&redirect_uri=http%3A%2F%2Fchat.flox.io%2Fsignup%2Fgitlab%2Fcomplete&state=*SNIPPED*

Manually modifying the redirect_uri parameter generated by GitLab will bring you to this screen. Note that in the page source, https is correctly used as the redirect_uri:

Clicking "Approve" redirects you to the following Mattermost screen:

And also generates this mattermost.log entry:

[2016/06/27 13:56:01 CDT] [EROR] /signup/gitlab/complete:AuthorizeOAuthUser code=500 rid=wq8fubqm6pd9zfs1zbc9uebz6a uid= ip=*SNIPPED*, *SNIPPED* Bad token type [details: token_type=]

Digging into GitLab's source, brings me here:

Here I'd thought I'd figured it out, and that force_ssl_in_redirect_uri would be the switch I needed to make this work, but alas toggling it to true didn't change anything.

A little lower in doorkeeper.rb I find this little gem:

So, I was even more confident I'd figured it out, but setting wildcard_redirect_uri true causes GitLab to not be able to restart, and several logs spit out a ton of not immediately identifiable solutions.

So, that's where I'm at currently, and I'll update this issue if I figure out the rest. <3

[JJJ]

Looks like wildcard_redirect_uri support was removed:

http://stackoverflow.com/questions/25775543/wildcard-support-for-doorkeeper-redirect-uris

And...

doorkeeper-gem/doorkeeper@fd57c47

[mildlyill]

@johnjamesjacoby I'm running into the same issue trying to run the stack behind a load balancer in rancher. Have you found a workaround?

[JJJ]

@mildlyill No workaround yet, but I'm about to update to the latest version of GitLab and look into this again. I'll report back once I've made some progress.

[JJJ]

So...

I have no idea what exactly the fix was, but updating to GitLab v8.10.5 and using Mattermost 3.3.0 RC 5, I'm finally able to successfully sign into Mattermost with our GitLab SSO.

[fculpo]

I fixed it by modifying Mattermost Nginx/Apache header (i'm using the docker production setup but it applies to classic setup or Gitlab Mattermost)

Change
proxy_set_header X-Forwarded-Proto $scheme;
to
proxy_set_header X-Forwarded-Proto https;

If you access your mattermost instance via a ssl configured reverse proxy / or load balancer, and that the bundled mattermost web server is configured as http only, its $scheme variable will pass "http" to GitLab, regardless of other settings, so you have to manually set it to "https" in order for gitlab to generate https callback links.

[JJJ]

That makes sense to me. We may have done the same inadvertently during an audit, not thinking it would fix this exactly.

[farahfa]

@fculpo: Did you add that to mattermost_nginx ? or gitlab's nginx?

btw, I'm on omnibus

[JJJ]

@farahfa Maybe both, maybe neither. Totally depends on your setup.

In our case, our GitLab server does not sit behind the load balancer, but our Mattermost server does. This is because we didn't want the load balancer worrying about balancing git traffic, not yet anyway.

So for us, both our load balancer and our GitLab server automatically 301 redirect non-HTTPS traffic to an https:// URL. For this issue specifically, all http:// requests will look for their https:// equivalents by the time they hit Mattermost.

Our load balancer does not communicate between web servers using SSL; it uses port 80 and nginx's proxy_pass, so our Mattermost config continues to use $scheme which means it will accept either http/https, and not complain about it, because by the time the requests get to Mattermost, the forwarded protocol/scheme has already been decided.

If your Mattermost installation is not behind a load balancer (meaning it is immediately world-accessible via some DNS) my recommendation would be to force to https as @fculpo suggested.

Either way, if you're running an entirely SSL setup using nginx for your web-servers, I would recommend server rules something like the following to force every incoming web request to serve the https:// variant:

server {
  listen      80;
  listen      [::]:80 ipv6only=on;
  rewrite     ^ https://$http_host$request_uri? permanent;
}

server {
  listen        443 ssl http2;
  listen        [::]:443 ssl http2;

  # Your stuff below
}

[JJJ]

@mildlyill Since updating to latest versions of GitLab, Mattermost, Nginx, and Ubuntu 16.04 on both servers, we have yet to see any recurrence of this issue. It's a lot of work, but I think my next suggestion is to get everything up-to-latest, pray for rain, and comment back here if there's no joy.

[farahfa]

Thank you @johnjamesjacoby for the information, our setup is as follows, both Gitlab and Mattermost are behind ELBs and the HTTPS is handled from the ELBs. Also our Gitlab's version is 8.10.7-ee.0 ...

Gitlab is an omnibus installation, and our gitlab.rb (related to this) is as follows:

external_url 'https://.git.company.com'

nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
 "Host" => "$http_host",
 "X-Real-IP" => "$remote_addr",
 "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
 "X-Forwarded-Proto" => "https",
 "X-Forwarded-Ssl" => "on"
}

mattermost_external_url 'https://chat.company.com'

mattermost['gitlab_enable'] = true
mattermost['gitlab_id'] = "2963984de0633e3d468cf5bc275f2782c877ebd49942333aff55afe241c8fec1"
mattermost['gitlab_secret'] = "b19f0f21395f062f05d682da25cdf3dd202e1db6aebe510c0feff669b34a55e7"
mattermost['gitlab_scope'] = ""
mattermost['gitlab_auth_endpoint'] = "https://git.company.com/oauth/authorize"
mattermost['gitlab_token_endpoint'] = "https://git.company.com/oauth/token"
mattermost['gitlab_user_api_endpoint'] = "https://git.company.com/api/v3/user"

mattermost_nginx['enable'] = true
mattermost_nginx['listen_port'] = 1234 
mattermost_nginx['listen_https'] = false
mattermost_nginx['proxy_set_headers'] = {
  "Host" => "$http_host",
  "X-Real-IP" => "$remote_addr",
  "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
  "X-Frame-Options" => "SAMEORIGIN",
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"
}

[farahfa]

Okay so I noticed that "X-Forwarded-Proto" => "https", from my gitlab.rb file does not work!! Like, X-Forwarded-Proto in gitlab-mattermost-http.conf (which is usually located in /var/opt/gitlab/nginx/conf/) looks like this:

proxy_set_header   X-Forwarded-Proto http;

So, I manually changed that to https and it worked.. However now I'm getting Token request failed after "Authorizing".. 😢 😭

[JJJ]

@farahfa You're welcome. I'll continue trying to help, based on our currently functioning setup.

Keep in mind, our infrastructure setups are a bit different. Here is ours, for context:

• 1 (very capable) nginx load balancer
• GitLab 8.11 Community Edition (Installed from source, not behind the LB)
• Mattermost 3.3.0 (Installed from source, behind the LB)

My best guess recommendation would be to try this on anything behind your load balancer:

"X-Forwarded-Proto" => "$scheme",

(I'm unsure if X-Forwarded-Ssl is necessary for you; we are not using that, neither on nor off.)

In addition, in your GitLab config, ensure that:

port: 80
https: true

(Our port is 443, because it's public. Your port should probably be 80, behind your load balancer.)

And in your Mattermost config, ensure:

"SiteURL": "https://urltoyourchat.com",
"AllowCorsFrom": "https://whatever https://whateverelse etc etc etc",

I'll keep looking around for other related configuration options, and update this reply if I find them.

---

(Sorry in advance for the configuration differences. Having not installed these 2 together in the traditional way means I'm not confident how the option keys map. Hopefully you're able to do so.)

[JJJ]

Something that's also easy to forget, after these configuration changes, remember to restart/reload the related services so that your changes take effect.

I'd even go as far as cleaning out cookies and local storage in your browser for both. We've seen intermittent cache weirdness in Mattermost after updates, and there are so many dependencies and moving parts that it's not immediately obvious if something is stuck, or if something needs a restart, etc...

[farahfa]

Yeah, I keep on restarting nginx everytime I do a manual change.. But still no luck. My problem now is different than OP's so maybe it's better to open a new issue rather than hijack this one.. I really do appreciate your help @johnjamesjacoby . 😄

EDIT: DOH!!! The error that I was getting was due to certificate problems which I've now fixed..

So for me @fculpo's solution worked best for me!

Note: If you're on an Omnibus installation and you changed X-Forwarded-Proto in your gitlab.rb.. That does not take effect in the actual nginx conf file for Mattermost!!! So you'll have to manually change it and restart nginx by running the following command: sudo gitlab-ctl restart nginx.. I hope this saves someone from the headache of figuring out what's going on! 😄

Update: The Nginx config problem was fixed in Gitlab version 8.11.2 (I believe).

[fculpo]

Great !

My setup is the following:
Gitlab Omnibus without Mattermost (Docker)
Mattermost stand alone + nginx webserver (Docker)

Both behind an nginx reverse proxy

I modified the $scheme from the nginx webserver serving mattermost (so the last one in the chain), because this one is configured to listen only in http, but nees to talk to gitlab as if it served https.

A clarified official documentation could be useful.

[jdoubleu]

Originally everything worked fine for me. After a few updates of both GitLab and Mattermost the authentication broke.
I tried a lot as described before but it didn't helped.

First of all, My Setup:
I'm Running GitLab and Mattermost inside docker containers behind a reverse proxy.
The reverse proxy has access to certificates so I can access both via HTTPS. The proxy communicates via HTTP with the Mattermost container and via HTTPS with the GitLab container.

As @johnjamesjacoby mentioned before the Mattermost SSO button generates a wrong uri, even in the desktop app (by the way it's a webkit frame opening the website).
I played around with configuration all nginx configs but it didn't helped.

How I solved this issue
In Mattermost there is an option for setting up its own url. This option was left blank by default and I set it to my Mattermost URL using HTTPS. Now the SSO button generates a correct link and GitLab detects it successful.

[doomsbuster]

Changing mattermost services urls to https in GitLab and then changing the mattermost_external_url in gitlab.rb fixed my issue. i am able to logon and use it now.

[frostyandy2k]

Had the same problem and the discussion above about the callback URIs led me to
Admin Area -> Applications -> Mattermost -> Callback URL

Turned out that I had a wrong URL listed "mattermost.example.com" and in gitlab.rb I had "mm.example.com". Changed it to the value in gitlab.rb and it worked like a charm.

[FaldeenOozeer]

Am having a similar issue but not wiht Mattermost but with Drone.
Drone is running behind a reserve proxy (Apache) no load balancer and gitlab is running on Omnibus with SSL (nginx).

I constantly get the same error.

[ledroide]

Same issue. Solved setting "Site URL" in general configuration options

[mhciael]

so in case anyone else finds this in my situation, i'm using docker (with traefik) to deploy a bunch of services (gitlab and mattermost included), and traefik (as proxy to all these services) handles the ssl, so i don't tell the individual apps (eg mattermost) to force/expect SSL, BUUUUUT I needed (as everyone here has been saying) to update my Site URL to have https anyway! working great. big ❤️s to all!