request.getUserPrincipal() имеет значение null в RequestListener, несмотря на то, что аутентификация прошла успешно

Question

У нас есть проблема с более поздними версиями Tomcat, которые не позволяют нам обновляться до версии позже, чем что-то вроде 7.0.22.

Мы используем FormBasedAuthentication с пользовательским диапазоном.

Это тестирование с Tomcat 7.0.57 и JDK 7u76 на Windows.

У меня есть форма входа, вызывающая сервлет j_security. Вызывается пользовательское царство и выполняется аутентификация, возвращается пользовательский принцип.

Tomcat затем перейдет на защищенный ресурс, и мы поймаем запрос в RequestListener.

Проблема в том, что request.getUserPrincipal() возвращает null. Отладчик раскрывает, что sessionwrapper, возвращенный request.getSession (false) (экземпляр SessionWrapper, содержащий StandardSession), имеет поле «main», в котором содержится директор, возвращенный из моей области.

Я видел обсуждение вопроса о возврате userprincipal для незащищенных запросов в bugzilla, но здесь запрашивается защищенный ресурс.

Любая идея о том, почему это может произойти, будет очень полезна. Фактически, я рассматриваю это как ошибку, что запрос не аутентифицирован, а все еще обслуживается.

Точно такая же настройка работает как шарм на Tomcat 7.0.12, и я думаю до 7.0.22.

С наилучшими пожеланиями,

Томас

Вот код запроса слушателя:

@Override 
public void requestInitialized(ServletRequestEvent event) { 
    if(log.isTraceEnabled()) { 
     log.trace(">> requestInitialized"); 
    } 
    HttpServletRequest request = (HttpServletRequest)event.getServletRequest(); 
    PortalRequest.current.set(request); 
    HttpSession httpSession = null; 
    GenericPrincipal genericPrincipal = (GenericPrincipal)request.getUserPrincipal(); 

// genericPrincipal is null, requestURI is pointing to a protected resource. 

Это конфигурация аутентификации формы в web.xml

<welcome-file-list> 
<welcome-file>jsp/main.jsp</welcome-file> 
</welcome-file-list> 

<security-constraint> 
<display-name>PDiX Portal</display-name> 
<web-resource-collection> 
    <web-resource-name>PDX Portal Protected</web-resource-name> 
    <url-pattern>/jsp/*</url-pattern> 
</web-resource-collection> 
<web-resource-collection> 
    <web-resource-name>servlets</web-resource-name> 
    <url-pattern>/servlet/*</url-pattern> 
</web-resource-collection> 
<web-resource-collection> 
    <web-resource-name>GWT Resourcen</web-resource-name> 
    <url-pattern>/StandardPortal/*</url-pattern> 
</web-resource-collection> 
<web-resource-collection> 
    <web-resource-name>services</web-resource-name> 
    <url-pattern>/delegating/*</url-pattern> 
</web-resource-collection> 
<web-resource-collection> 
    <web-resource-name>ViewerServlet</web-resource-name> 
    <url-pattern>/frameset</url-pattern> 
    <url-pattern>/run</url-pattern> 
</web-resource-collection> 
<web-resource-collection> 
    <web-resource-name>EngineServlet</web-resource-name> 
    <url-pattern>/preview</url-pattern> 
    <url-pattern>/download</url-pattern> 
    <url-pattern>/parameter</url-pattern> 
    <url-pattern>/document</url-pattern> 
    <url-pattern>/output</url-pattern> 
    <url-pattern>/extract</url-pattern> 
</web-resource-collection> 
<auth-constraint> 
    <role-name>authenticatedUser</role-name> 
</auth-constraint> 

ФОРМА PDXRealm /jsp/login.jsp /logout.jsp?error=true authenticatedUser

[обновленный вопрос, чтобы отразить связь с запросом слушателя]

Answer 1

Проблема была решена с помощью Константина Колинко в списке пользователей tomcat.

Начиная с Tomcat 7.0.22 аутентификация происходит после запуска прослушивателя запросов сервлета. Это имеет побочный эффект, что прослушиватель запросов больше не может использоваться для настройки аутентификации приложения в сеансе.

Цитирую Константин:

Существует следующие изменения для версии 7.0.22 в файле изменений:

[quote] Исправить регрессию с исправлением для 51653, которое нарушило пользовательские страницы ошибок для ответов 4xx от аутентификаторов. Обработка ошибок и запросы слушателей теперь обрабатываются в StandardHostValve до , гарантируя, что они завершают всю активность на уровне контекста. (markt) [/ quote]

Итак, мое решение состоит в том, чтобы найти другой способ настроить мои вещи, и это, скорее всего, фильтр.

Я просмотрел спецификацию Servlet 3.0, чтобы найти какой-либо намек на состояние запроса на вызов requestInitialized(), но никаких конкретных требований нет (или я их не нашел).

Надеюсь, что кто-то еще найдет это полезным.