☰

Как определить причину ошибки 403 на сервере JBoss WildFly?

tag-icon • tag-icon logging configuration jboss http-status-code-403 wildfly
Как определить причину ошибки 403 на сервере JBoss WildFly?

Мы запускаем приложение AngularJS на JBoss WildFly. Раньше оно работало нормально и в нашей тестовой среде, и в продакшне. Однако сейчас в продакшне появилась странная ошибка 403.

Пользователи могут загружать данные с помощью запроса REST. На одном сайте установлен файл cookie для хранения параметра фильтра. После установки файла cookie все последующие запросы завершаются неудачей и отображается ошибка 403 (Forbidden).

Локально и на нашем удаленном тестовом сервере эта проблема не существует. В продакшене она тоже работала, но что-то, должно быть, изменилось. Это происходит во всех браузерах и для всех пользователей, поэтому я предполагаю, что наш ИТ-отдел, должно быть, изменил конфигурацию сервера. Однако я не могу понять основную причину проблемы.

Сервер отвечает следующими заголовками:

Server: Apache
X-Powered-By: Undertow/1

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

У меня есть вопросы:

  1. Где JBoss регистрирует запросы к веб-серверу? Есть ли дополнительный файл журнала доступа ( /var/log/apache2/error.logне существует)?

  2. Почему заголовок утверждает, что сервер Apache? standalone.xmlФайл JBoss устанавливает "WildFly/9". Есть ли другой сервер, обрабатывающий запросы между ними? Как узнать?

  3. JBoss или Apache вообще регистрируют причину таких ошибок? Нужно ли мне повышать уровни логирования?

После удаления куки сайт снова работает нормально. Я уверен, что это просто небольшая проблема с конфигурацией, так как раньше все работало, но сейчас я не могу разобраться. Буду очень признателен за любые подсказки.

решение1

Добавьте этот блок standalone.xmlв подсистему urn:jboss:domain:logging:3.0:

<logger category="org.jboss.security">
  <level name="TRACE"/>
</logger>

Перезапустите сервер, чтобы он принял новую конфигурацию.

Теперь выполните взаимодействия, вызывающие ошибку 403. Более подробная информация будет записана в server.logфайл сейчас. Это помогло мне получить сведения о первопричине проблемы, по крайней мере. Похоже, что сопоставление ролей из Active Directory не удается. Однако все еще нужно исследовать дальше.

Но, по крайней мере, увеличение уровня журнала, как описано выше, помогло мне в отладке.

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