Невозможно войти в GitLab Web UI через Google Chrome

Невозможно войти в GitLab Web UI через Google Chrome

Я пытаюсь настроить GitLab на сервере CentOS 7, который запущен в моей локальной сети, чтобы у меня было где хранить и синхронизировать мои файлы и проекты в течение предстоящего семестра. Я следовал инструкциям по установке для пакета omnibus, который нашелздесь.

Теперь, после настройки, я не смог войти в систему как пользователь root. С тех пор я обнаружил, что могу использовать Microsoft Edge для аутентификации, но Google Chrome не работает. Я утверждал, что поведение одинаково независимо от того, захожу ли я на сайт через IP или адрес (локально назначенный на DNS-сервере маршрутизатора). Когда я пытаюсь войти в систему с помощью Chrome, веб-приложение зависает, постоянно загружаясь.

Я использовал gitlab-ctl для проверки логов NGINX, и похоже, что запрос POST просто не проходит, когда я использую chrome. Вот пример вывода:

==> /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"

Я пробовал очистить историю просмотров/кэш/cookies в надежде, что это поможет разобраться с чем-то, что могло застрять во время настройки GitLab, но ничего не помогло. Должен отметить, что я открыл только порт 80 через firewalld, а не порт 443. Я планирую запустить GitLab только через HTTP. Успех Microsoft Edge в доступе и аутентификации на сайте говорит мне, что настройка GitLab таким образом не должна быть проблемой.

Кто-нибудь знает, в чем может быть проблема?

Я бегу CentOS Linux release 7.6.1810 (Core), GitLab Version 12.1.6-ee Revision d05ee0a9c12, иGoogle Chrome 76.0.3809.87 (Official Build) (64-bit)

решение1

Для тех, кто столкнулся с подобной проблемой, я нашел причину:

Домен верхнего уровня gitlab.lan, .lan, не зарегистрирован средиБаза данных TLD IANA. По-видимому, некоторые браузеры не разрешают определенные типы подключений (в данном случае Chrome не разрешал метод POST) к доменам, если домен не является официальным TLD.

Теперь, в своем вопросе, я сказал, что доступ по IP тоже не работает. Я думаю, что эта проблема возникла, когда я настроил GitLab, указав домен, к которому он будет прикреплен, как gitlab.lan. Я ожидаю, что GitLab рендерил ссылки на себя, используя этот адрес. Таким образом, он попытается выполнить POST, независимо от того, gitlab.lanполучил ли пользователь доступ к сайту по IP или домену.

Решением было использовать действительный TLD вместо .lanдомена веб-сайта ( .com, .net, и т. д.).

Что касается того, какие браузеры проверяют доменные TLD перед доступом к веб-сайту, Chrome, похоже, не делает этого, а Edge, похоже, вообще не проверяет. Пробег, похоже, варьируется, и я ожидаю, что поведение будет неопределенным или будет регулярно меняться, поэтому я не буду документировать здесь, какие браузеры ведут себя каким образом.

Связанный контент