2012-04-17 5 views
3

Мы имеем следующую ситуацию:Игнорировать кук для конкретной URI, в Tomcat

JSESSIONID посылается оба печеньем и URL, но из-за Adobe Flash BUG, ​​они разные (на самом деле, печенье JSESSIONID неправильно) ,

Что мы хотели бы сделать, это использовать URL JSESSIONID вместо того, который был отправлен в файлы cookie. Другими словами, когда я выполняю request.getSession(), он должен вернуть HttpSession, связанный с ID в URL, а не в cookie.

Мы изучили исходный код Tomcat7, и, по сути, Tomcat сначала анализирует URL-адрес, ища идентификатор. Затем он переопределяет его с помощью файлов cookie SESSIONID, если они присутствуют. Вот код пропущено в CoyoteAdapter.java (7.0.26 кот):

 String sessionID = null; 
     if (request.getServletContext().getEffectiveSessionTrackingModes() 
       .contains(SessionTrackingMode.URL)) { 

      // Get the session ID if there was one 
      sessionID = request.getPathParameter(
        SessionConfig.getSessionUriParamName(
          request.getContext())); 
      if (sessionID != null) { 
       request.setRequestedSessionId(sessionID); 
       request.setRequestedSessionURL(true); 
      } 
     } 

     // Look for session ID in cookies and SSL session 
     parseSessionCookiesId(req, request); 
     parseSessionSslId(request); 

Мы могли отключить куки JSESSIONID на всех, но мы не можем, потому что мы используем его для всех URL-адресов на веб-сайте. Мы хотели бы отключить файлы cookie для ПРОСТОГО СПЕЦИФИЧЕСКОГО URL.

Возможно ли это? Есть ли другая идея или решение проблемы для решения этой проблемы?

ответ

-1

Вы можете реализовать пользовательский servlet filter, который заменит объекты запроса, ответа и сеанса вашими собственными оболочками. Затем обертки могут вести себя по-разному на основе URL-адреса, например. делегировать или нет оригинальному экземпляру сеанса. Хотя вы не сможете получить доступ к данным сеанса для какого-либо другого идентификатора, не изменяя код Tomcat.

+0

Это не работает, потому что, когда фильтр выполняется, объект сеанса уже построен (что означает, что cookie-jsessionid использовался до того, как мы попали в Фильтр). –

+0

Вы протестировали его? Я уверен, что экземпляр сеанса не создается/не восстанавливается до первого вызова getSession(). –

+0

Да. Мы тестировали это :-) - мы также пытались использовать Valves, но у нас была та же проблема. Верно, что сеанс не создается до первого вызова getSession(), но sessionId уже связан с запросом (как показано в приведенном выше коде) –

Смежные вопросы