"Invalid state" while trying to use alternate server name

Troubleshooting
1

Summary

Trying to log in via an alternate server name produces a page showing “Invalid State”.

Steps to reproduce

  • Mattermost 4.1.0, with auth delegated to gitlab enterprise.
  • Server is reachable by two aliases, mattermost and mattermost.my.internal.domain. Nginx listens on both server names and the certificate is signed for both names.
  • Gitlab application lists callbacks for both server names (e.g. mattermost/login/gitlab/complete and mattermost.my.internal.domain/login/gitlab/complete).
  • Logging in via mattermost works as expected.
  • Navigate to mattermost.my.internal.domain and try to log in.

Expected behavior

Logging in works via either server alias.

Observed behavior

When trying to log in via the second alias:

  • the gitlab login button is shown (URL is https://mattermost.my.internal.domain/login)
  • clicking the button leads to the page https://mattermost/error?message=Invalid%20state which shows the message “Invalid state”
2

In case the use case is not clear: users use the short alias when possible, but the longer alias with domain is sometimes required, e.g. for a vpn to automatically identify it.

I don’t really understand why the server would move from one server name to the other in the URL. Nothing in the config should prefer one over the other as far as I can see, unless the SiteURL setting (which is set to the short name) is important?

3

Hi @gubbins,

I believe the SiteURL is important. Have you tried setting that to the longer name to see whether the issue still persists?

4

I didn’t want to make the main site unreachable. But I just tried this experiment on our test server and confirmed that you can only sign in using the SiteURL server name. I changed it to the longer name in the config and restarted and then I was unable to sign in using the short name.

I am sure that this used to work… we set things up to work with both server names quite early on for this reason and did the work to sign the certificate properly, etc. I am not sure when it stopped working.

5

What is the AllowCorsFrom config.json setting set to? It’s also in System Console > Connections > Enable cross-origin requests.

https://docs.mattermost.com/administration/config-settings.html#enable-cross-origin-requests-from

I think if you include both domains here, navigating from either domain should work.

6

Hi @gubbins,

I’ve set up my test server similarly, and I’m seeing the same issue where it always sends you to the URL configured as the SiteURL after logging in, breaking login with the other URL. I’m checking with another one of our members to see if there’s a way that we could make this setup work

7

@jasonblais it was empty. I tried setting it to:

  • https://mattermost.my.internal.domain
  • https://mattermost https://mattermost.my.internal.domain
  • mattermost.my.internal.domain
  • mattermost mattermost.my.internal.domain
  • *

Same behaviour in all cases I’m afraid.

@hmhealey thanks for looking into it

8

Alright, it looks like we’d need a code change to get this working with multiple URLs. The problem is that Mattermost is always sending a redirect URI to GitLab always using the SiteURL in the config.json, not from the URL that the user is connecting with in the first place. I’ll create a ticket to get this added in.

Edit: Here’s the ticket https://mattermost.atlassian.net/browse/PLT-7541