GitLab Web UI Login not working in Chrome

I’ve been trying to get GitLab set up on a CentOS 7 server I have running on my local network so I have somewhere to store and sync my files and projects during the upcoming semester. I followed the install instructions for the omnibus package installation found here.

Now, after setting it up, I was unable to log in as the root user. I’ve since found that I can use Microsoft Edge to authenticate, but Google Chrome doesn’t work. I’ve asserted that the behavior is similar regardless of whether I access the site via IP or address(locally-assigned in the router DNS server). When I try to log in using Chrome, the web application hangs, perpetually loading.

I’ve used gitlab-ctl to check NGINX’s logs and it looks like the POST request simply isn’t going through when I use chrome. Here’s some sample output:

==> /var/log/gitlab/nginx/gitlab_access.log <==
192.168.1.52 - - [18/Aug/2019:18:15:47 -0600] "GET / HTTP/1.1" 302 98 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:15:57 -0600] "POST /users/sign_in HTTP/1.1" 302 85 "http://192.168.1.2/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:15:57 -0600] "GET / HTTP/1.1" 200 8684 "http://192.168.1.2/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:03 -0600] "GET / HTTP/1.1" 200 8673 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:06 -0600] "GET /users/sign_out?nav_source=navbar HTTP/1.1" 302 97 "http://gitlab.lan/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:06 -0600] "GET /users/sign_in HTTP/1.1" 200 4718 "http://gitlab.lan/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
192.168.1.52 - - [18/Aug/2019:18:16:12 -0600] "POST /users/sign_in HTTP/1.1" 302 84 "http://gitlab.lan/users/sign_in" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"

I’ve tried clearing browsing history/cache/cookies in hopes that it would sort out something that may have gotten stuck while I was configuring GitLab, but nothing has seemed to help. I should mention that I’ve only opened port 80 via firewalld, not port 443. I plan to run GitLab over only HTTP. Microsoft Edge’s success in accessing and authenticating with the site indicates to me that configuring GitLab this way isn’t the issue.

Does anyone know what the problem could be?

I’m running CentOS Linux release 7.6.1810 (Core), GitLab Version 12.1.6-ee Revision d05ee0a9c12, and Google Chrome 76.0.3809.87 (Official Build) (64-bit)

Me too. In my case this is a new install of Gitlab CE (Omnibus) on Ubuntu 18, just using http:// on a private local server.

Using tail-f on the gitlab_access.log shows me the same artifact: Chrome fetches the login page, but the POST never arrives.

What’s extra weird is that I can sign in with Chrome with a completely different google chrome user account, no issues at all.
Firefox also works fine.
Clearing the cache and cookies on the “bad” account doesn’t fix it.
Using incognito mode with the “bad” account doesn’t fix it.
Using the Chrome “open guest window” works just fine.
I’m baffled!

I discovered that the issue was related to Chrome’s method of handling top-level domains. Apparently, if the address you’re navigating to isn’t a TLD, Chrome won’t allow the POST method.

I expect there’s more going on here, and I don’t know if this is documented behavior, but I was wrong in thinking the issue was with GitLab. In the end, switching the domain from ‘.lan’ to ‘.com’ fixed the issue.

I fixed my issue - I have not set up https support (yet) for my local Gitlab CE Omnibus install.
In Chrome, I clicked on the warning flag to the left of the URL bar (Latest chrome on Windows 7) to see the security warnings for my gitlab web portal, and found that “allow redirects” was turned off for my Gitlab site (to prevent phishing etc).
Allowing redirects for my Gitlab site fixed the problem.
I’m guessing the login page issues a redirect when you sign in, and Chrome was blocking this from happening to save me from attack.

Much better now thanks…

Just FYI, for a .local domain, explicitly enabling “allow redirects” did not fix the problem for me.

No fun!
I did find that in one instance, Chrome was set to allow redirects for my Gitlab URL, but it wasn’t working.

I disabled redirects and re-enabled them again and that fixed the issue there. Might be worth a try in your case.

Thanks for the idea! Just tried it, no luck.

The non-https local domain is probably a niche usecase, but one perhaps useful hint. It used to be that when I logged-in on Chrome, I would submit my credentials and press login, then nothing would happen. But if I reloaded the page, I would be already-logged in.

Recently (maybe the last 3 months?) this workaround stopped working. Dunno if it was because we upgraded GitLab or because of a change in Chrome.