Zammad: Ответы HTTP 401, вызывающие проблемы с базовой аутентификацией

Пожалуйста, обновите свою первую статью, чтобы сохранить точную информацию об установке - «любой» на данном этапе не подходит - извините. :)

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

Спасибо.

Привет еще раз,
Я обновил описание проблемы - извините за его отсутствие вначале!
Лучший

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

Спасибо!

Да, это просто Zammad Default config + Basic Auth. Вот конфигурация vhost:

auth_basic 'Restricted: general basic auth';
auth_basic_user_file /etc/.htpasswd.d/zammad;
location /ws {
    proxy_pass  http://zammad_ws;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  443;
    proxy_set_header CLIENT_IP $remote_addr;
    proxy_read_timeout 86400;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    error_page 502 503 504 =503 @fallback;
}
location / { 
    try_files $uri @proxy;
}
location <strong i="6">@proxy</strong> { 
    proxy_pass  http://zammad;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto https;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  $server_port;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    proxy_set_header CLIENT_IP $remote_addr;
    error_page 502 503 504 =503 @fallback;
}

Мы изучили это снова.
Мы предполагаем (как писал Майкл) не возвращать HTTP 401 (что заставляет браузер полагать, что данные базовые учетные данные неверны), а возвращать HTTP 403 запрещено.

Если бы я увидел это правильно, это означало бы

приложение / контроллеры / application_controller / handles_errors.rb # L39
respond_to_exception(e, :unauthorized)

следует заменить на
respond_to_exception(e, :forbidden)

RFC говорит, что браузеры должны вести себя по-другому (https://tools.ietf.org/html/rfc7231#section-6.5.3): «Если в запросе были указаны учетные данные для аутентификации, сервер считает их недостаточными для предоставления доступа. Клиенту СЛЕДУЕТ НЕ повторять автоматически запрос с теми же учетными данными ".

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

Лучший

Извините, что так долго.
Обратите внимание, что это не проблема, связанная с Zammad (на основе приложения), а «проблема с серверной частью» вашего nginx.

Запросы аутентификации для базовой аутентификации никогда не доходят до Zammad как приложения, но уже завершаются (и проверяются) вашим nginx или любым другим веб-сервером, который вы бы использовали.

Таким образом, изменение исходного кода, на мой взгляд, не решает вашу проблему.
Технически неавторизованный 401 правильный, насколько я могу судить (хотя я понимаю, что вам нужен 403).

Смотрите также:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

Кстати:
Чтобы дважды проверить, я полностью закомментировал части прокси Zammad, чтобы серверная часть Zammad не могла ответить. Результат с 401 такой же и, следовательно, ошибка nginx. :)

Закрытие, так как это не ошибка, а технический вопрос.

Привет, @MrGeneration!
спасибо, что изучили это.

Хотя я понимаю, что эта проблема выходит за рамки приложения Zammad, я все же думаю, что она вызвана им (а не Ngnix). Попробую объяснить почему:

Предположим, наш ngnix _не_ настроен на использование базовой аутентификации. В этом случае мы оба согласны с тем, что приложение Zammad («за» ngnix) работает нормально.

Теперь мы включаем базовую аутентификацию, добавляя указанную выше конфигурацию в наш ngnix. Обратите внимание, что даже сейчас почти все работает должным образом, включая аутентификацию (базовую и Zammad) и само приложение Zammad.

Проблема, которую я пытался описать ранее, иногда возникает позже (Заммадом!), Когда приложение отображает страницу с кодом состояния 401. В этом случае _ любой веб-сервер_ с включенной базовой аутентификацией будет вынужден выйти из системы.

Я согласен с тем, что с семантической точки зрения 401 в данном случае звучит «в самый раз». С технической точки зрения, это неизбежно вызывает проблемы с базовой аутентификацией, и его следует заменить на 403.
Пожалуйста, повторно откройте эту проблему, поскольку она также может повлиять на UX приложения Zammad для многих пользователей.

@thorsteneckel, что ты

Привет, ребята! Спасибо за ценную информацию и описания. Я прочитал RFC и все еще был немного смущен различиями между 401 и 403. Однако я нашел это отличное объяснение на StackOverflow. Цитировать:

Проблема с кодом состояния HTTP 401 Unauthorized для ошибок аутентификации. Вот и все: это для аутентификации, а не для авторизации.

Это подводит нас к сути. Заммад использует 401 для ошибок authorization . Это технически неправильно и, следовательно, является ошибкой. Я снова открою вопрос.

Однако нам нужно проверить удар. Я предполагаю, что это критическое изменение из-за всех реализаций и потребителей API.
Мой текущий план состоит в том, чтобы мягко исключить 401 authorization с помощью Zammad 3.4, жестко отказаться от него с помощью 3.5 (или 3.6) и перейти на 403.
Нам нужно обсудить это внутри компании.

Дальнейшие мысли по этому поводу?

Это отличные новости! Звучит неплохо.

Чтобы держать вас в курсе: мы реализуем это в предстоящем выпуске 4.0.

Для внутренней реализации: https://oughttbot.com/blog/forbidden-kisses-http-fluency-in-clearance.

Исправлено с фиксацией выше. Мы рискнули и улучшили некоторые сообщения об ошибках 401 но в основном единственное, что мы изменили, - это ошибки, не связанные с аутентификацией, на 403 Forbidden .

Вы можете проверить это с последним пакетом develop примерно через 30 минут. Имейте в виду, что это рабочая ветка, а не стабильная. Поэтому обязательно сделайте резервную копию и ожидайте худшего :) Жду ваших отзывов!