Запуск sonarqube в Docker продолжает перенаправлять меня обратно на страницу входа

У меня уже давно работает SonarQube, но я не использовал его очень часто, но в целом, похоже, все работает. Я запускаю его внутри Docker.

Я только что обновил его до LTS (6.7), и после этого он, похоже, перешел в состояние неопределенности. Я могу войти в систему и просматривать веб-сайт, но как только я пытаюсь выполнить какую-либо операцию (кажется, не имеет значения, что это за операция), меня перенаправляют на страницу входа. Если я снова захожу, все повторяется. Так что я не могу на самом деле выполнить какое-либо действие, кажется.

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

Например, после чистой настройки я вхожу в систему с правами admin/admin и получаю «учебник для первого раза», где мне предлагают создать токен. Я пытался это сделать, но меня перенаправили на страницу входа. Я снова вхожу в систему и на этот раз пытаюсь пропустить учебник, но затем меня перенаправляют на страницу входа. Ниже приведена часть файла access.log, когда я пытаюсь пропустить учебник:

10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "POST /gor-sq/api/users/skip_onboarding_tutorial HTTP/1.0" 401 - "https://build.acme.com/gor-sq/projects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA4"
10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "GET /gor-sq/api/users/identity_providers HTTP/1.0" 200 24 "https://build.acme.com/gor-sq/sessions/new?return_to=%2Fgor-sq%2Fprojects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA5"
10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "GET /gor-sq/api/navigation/global HTTP/1.0" 200 573 "https://build.acme.com/gor-sq/sessions/new?return_to=%2Fgor-sq%2Fprojects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA6"

Первая строка указывает, что POST получает ответ 401. Не будучи абсолютно уверенным, похоже, что операции POST получают ответы 401, пока работает GET.

Эта настройка находится за обратным прокси-сервером, но, как я уже говорил, раньше установка работала нормально, и в настройку обратного прокси-сервера не было внесено никаких изменений.


redirect sonarqube sonarqube-ops
person StFS    schedule 16.11.2017    source источник
comment
Вы проверяли/сравнивали файл конфигурации SonarQube?   -  person Jeroen Heier    schedule 16.11.2017
comment
@JeroenHeier, как я уже сказал, во второй раз, когда я устанавливал, я сделал совершенно новую установку, поэтому файл конфигурации был тем, который поставлялся с SonarQube. Тем не менее, я попытался запустить sonarqube полностью автономно (запустил docker run sonarqube на своем ноутбуке, и он работал нормально. Так что это должно быть как-то связано с моей конкретной настройкой.   -  person StFS    schedule 16.11.2017

Ответы (2)


arrow_upward
2
arrow_downward

Надеюсь, я не так опоздал. Я была такая же проблема. Что сработало для меня, так это удаление файлов cookie из браузера, а все остальное работает как шарм.

person Peter Smith    schedule 26.08.2018

arrow_upward
1
arrow_downward

Я была такая же проблема. https://myserver.com/sonar/api/users/skip_onboarding_tutorial я получил 401 и меня перенаправили на страницу входа. Я посмотрел исходный код, и request.ts выдал ошибку в строке 108.

submit(): Promise<Response> {
const { url, options } = this.getSubmitData({ ...getCSRFToken() });
return window.fetch((window as any).baseUrl + url, options);}

Похоже, проблема с CSRFToken. Поскольку у меня Sonarqube работает за обратным прокси-сервером Nginx, возможно, что-то связано с тем, как я обрабатывал файлы cookie.

Поэтому, когда я немного посмотрел, я нашел решение здесь: https://stackoverflow.com/a/47909810/3221249

По сути, они изменили способ обработки безопасных файлов cookie после версии 6.0. Поскольку я делал cookie безопасным и httponly для true (не позволяя клиентскому браузеру взаимодействовать с кодом js), у меня возникла вышеуказанная проблема. Я делал это еще до того, как мой не-ssl-трафик попал в Nginx. У меня есть другой прокси-сервер с HAProxy, который обрабатывал это, поэтому я прокомментировал эту часть определений.

#rspirep ^(Set-cookie:.*) \1;\ Secure if ! secure
#rspirep ^(Set-cookie:.*) \1;\ httponly

Я надеюсь, это поможет вам.

person vibhuyadav    schedule 08.03.2018