Как исправить доступ к запрошенному ресурсу, который был запрещен для Tomcat webapp?

Статус HTTP 403 (доступ к запрошенному ресурсу был запрещен) может указывать на то, что вы ввели 3+ неверных учетных данных (попробуйте другой веб-браузер) или у вас возникли проблемы с конфигурацией.

Если вы не меняли какие-либо файлы конфигурации, проверьте файл conf/tomcat-users.xml в вашей установке (locate tomcat-users.xml). Этот файл должен содержать учетные данные, чтобы вы могли использовать Tomcat webapp.

Например, чтобы добавить роль manager-gui пользователю с именем tomcat с паролем s3cretдобавьте следующее в файл конфигурации, указанный выше:

<role rolename="manager-gui"/>
<user username="tomcat" password="s3cret" roles="manager-gui"/>

Затем вы можете получить доступ к своему менеджеру веб-приложений из /manager/html (например, перезагрузка после изменения конфигурации).

Читать далее: Приложение Manager КАК

Если вы пытаетесь реализовать собственное ограничение безопасности (в web.xml) попробуйте следующий пример (до </web-app> окончание):

<!-- This security constraint protects your webapp interface. -->
<login-config>
  <!-- Define the Login Configuration -->
  <auth-method>BASIC</auth-method>
  <realm-name>Webapp</realm-name>
</login-config>
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Admin</web-resource-name>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>*</role-name>
  </auth-constraint>
  <!-- Specifying a Secure Connection -->
  <user-data-constraint>
    <!-- transport-guarantee can be CONFIDENTIAL (forced SSL), INTEGRAL, or NONE -->
    <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>
</security-constraint>
<!-- Authorization, see: tomcat-users.xml --> 
<security-role>
  <role-name>*</role-name>
</security-role>

Если проблема не исчезла, попробуйте:

• проверьте, редактируете ли вы правильный XML-файл,
• проверьте свои XML-файлы, например catalina.sh configtest или xmlstarlet val /etc/tomcat?/*.xml /var/lib/tomcat7/webapps/*/WEB-INF/*.xml,
• ваш <url-pattern> совпадения в вашем <security-constraint> или установить на /*,
• проверьте свои журналы Tomcat (например, /var/log/tomcat7),
• увеличить уровень ведения журнала (INFO -> FINE/FINEST) в logging.properties или log4j.properties (ИНФОРМАЦИЯ, СЕРЬЕЗНО, ПРЕДУПРЕЖДЕНИЕ, ИНФОРМАЦИЯ, КОНФИГУРАЦИЯ, ТОЧНО, ТОЧНО, НАИЛУЧШЕЕ или ВСЕ), перезапустите Tomat и проверьте журналы,
• если в журналах ничего нет, проверьте, проверяете ли вы нужные журналы (sudo lsof | grep -E "java.*(out|txt|log)$", tail -f /var/log/tomcat7/*.log /var/log/tomcat7/*.txt /var/log/tomcat7/*.out),
• когда используешь log4j система регистрации, убедитесь, что вы правильно инициализировал поместив библиотеки и log4j.properties в нужную папку и настроив ее,

• протестировать BASIC аутентификацию с помощью cURL:

  • без учетных данных:

    $ curl -vv http://example.com:8983/solr/
    

    Обычно запрос должен возвращаться HTTP / 1.1 401 Неавторизованный и "WWW-аутентификация"заголовок должен указывать Базовый требуется аутентификация.

  • с учетными данными:

    $ curl -vv -u tomcat:tomcat http://example.com:8983/solr/
    

    Запрос должен быть отправлен с заголовком «Авторизация» и должен пройти аутентификацию. Если ваши учетные данные недействительны, вы должны получить: HTTP / 1.1 401 Неавторизованный. Если пользователь аутентифицирован, но не имеет доступа для просмотра ресурса, вы должны получить: HTTP / 1.1 403 Запрещено.

• возможно, был активирован механизм блокировки пользователя для слишком много неудачных попыток аутентификации (LockOutRealm),

• остановите и запустите Tomcat вручную (так же, как в: ps wuax | grep ^tomcat), например:

  # ps wuax | grep ^tomcat
  tomcat7    884  /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties ... org.apache.catalina.startup.Bootstrap start
  $ /etc/init.d/tomcat7 stop
  $ sudo sudo -u tomcat7 /usr/lib/jvm/java-7-openjdk-amd64/bin/java ...  -Dorg.apache.catalina.level=FINEST org.apache.catalina.startup.Bootstrap start
  

  В качестве альтернативы начните использовать catalina.sh сценарий вроде:

  $ . /etc/default/tomcat7
  $ export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 CATALINA_HOME=/usr/share/tomcat7 CATALINA_BASE=/var/lib/tomcat7 CATALINA_PID=/var/run/tomcat7.pid CATALINA_TMPDIR=/tmp LOGGING_CONFIG="-Dorg.apache.catalina.level=FINEST"
  $ /usr/share/tomcat7/bin/catalina.sh run
  

  Или в режим отладки:

  $ JPDA_SUSPEND=y catalina.sh jpda start
  

  и проверь свой catalina.out журнал.

• последнее средство - отладить процесс: sudo strace -fp PID.

Убедитесь, что у пользователя, который запускает Tomcat, есть доступ к папке, в которой находится FreeShim.

sudo chmod -R a+rwx < dir of FreeShim >

Это сработало для меня.