带有< path> /< / path>和JSESSIONID [英] cookies with <path>/</path> and JSESSIONID

查看:241
本文介绍了带有< path> /< / path>和JSESSIONID的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在应用程式的web.xml(如建议的



…在Tomcat日志上我看到:

 没有会话 - 使用JSESSIONID = [A227B147A4027B7C37D31A4A62104DA9]创建的新会话

到目前为止很好。当我然后访问 application-b 这是我看到的:



,还可以在此答案中引用:


SRV.7.3会话范围



HttpSession对象必须在应用程序(或servlet
上下文)级别进行作用域。底层机制,例如用于
建立会话的cookie,对于不同的上下文可以是相同的,但引用的
对象,包括该对象中的属性,永远不能共享


所以即使在请求上存在JSESSIONID cookie,我的应用程序c $ c> application-b )无法在自己的servlet上下文范围中找到HttpSession对象,因此创建了一个新的会话对象,并将一个新值分配给JSESSIONID cookie。



然而,当我现在回到我的应用程序 - a 我发现,为cookie路径配置的 / 值,它现在尝试使用由 application-b 设置的JSESSIONID值;当然,它的servlet在其自己的上下文中没有找到这样的会话对象( application-a ),因此创建了JSESSIONID cookie的新值, application-b 应用程序的会话等等无限制地在两个应用程序之间来回切换。



所以我的问题是:



1 给定上述行为,两个应用程序似乎不可能使用相同的JSESSIONID cookie值作为它们各自的HttpSession对象的密钥。因此,事实上,不仅HttpSession对象总是不同的,并在应用程序(servlet上下文)级别范围,而且在实践中,JSESSIONID值必须不同。是否正确?



2 < a>如果是这样,那么为什么servlet规范使用以下措辞:


底层机制,例如用于建立$ [...]


我可以想象以上的唯一方法是完成将有一个方法硬编码提供JSESSIONID值,当创建一个新的会话对象时使用?但我没有看到一个API。



3 有一种方法,我可以使用>中的 / 路径在应用程序之间共享一些其他的cookie。 XML元素,但是没有将 / 路径应用于JSESSIONID cookie?换句话说,< session-config>适用于应用程序的所有Cookie或仅用于会话跟踪的Cookie? (JSESSIONID)?

解决方案

进一步尝试并从这个答案,似乎对于相同的JSESSIONID要用于所有Web应用程序,有必要在context.xml中设置以下属性:

 < Context ... sessionCookiePath =/> 

Tomcat范围的context.xml b> WAR特定的context.xml会做。在WAR的web.xml中配置的< cookie-config>< path> 值显然被忽略。所以在这一点上,即使我已经解决了这个问题,仍然不清楚的是< cooke-config>< path> 元素应该用于。



关于我的问题的点 3 ,我发现为其他cookie设置路径的方式是以编程方式创建其中的许多,每个路径一个,并在响应对象中添加 addCookie 方法。 web.xml context.xml 中的配置适用于会话cookie之外的其他cookie。


I am experimenting with setting the cookie path in my application's web.xml (as suggested here) to:

<session-config>
    <cookie-config>
        <path>/</path>
    </cookie-config>
</session-config>

So I deploy two identical web applications to localhost:8080/application-a and localhost:8080/application-b respectively.

Each application is a single servlet:

public class ControllerServlet extends HttpServlet{
  @Override
  public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
      HttpSession session = req.getSession(false);

      if (session == null) {
          session = req.getSession(true);
          System.out.printf("No session was present - new one created with JSESSIONID=[%s]\n", session.getId());
      } else {
          System.out.printf("JSESSIONID cookie was present and HttpSession objects exists with JSESSIONID=[%s]\n", session.getId());
      }
  }
}

I deploy the apps to a Tomcat 8.5 container (tried with Tomcat 9 as well the behavior is the same). When I visit with my browser the application-a, here's what I see:

… and on the Tomcat logs I read:

No session was present - new one created with JSESSIONID=[A227B147A4027B7C37D31A4A62104DA9]

So far so good. When I then visit application-b here's what I see:

… and the Tomcat logs show:

No session was present - new one created with JSESSIONID=[5DC8554459233F726628875E22D57AD5]

This is also very well as explained here and also in this answer and I quote:

SRV.7.3 Session Scope

HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.

So even though on the request the JSESSIONID cookie was present, my application (the one deployed in application-b) was unable to find an HttpSession object in its own servlet context scope and so a new session object was created and a new value was assigned to the JSESSIONID cookie.

However, when I now go back to my application-a I find out that because of the / value configured for the cookie path, it is now trying to use the JSESSIONID value set by application-b and of course its servlet doesn't find such a session object in its own context (application-a) and so a new value for the JSESSIONID cookie is created which will in turn invalidate the session of the application-b application and so on and so forth ad infinitum as I switch back and forth between the two applications.

So my questions are:

1 given the above behavior it would seem impossible for two applications to use the same JSESSIONID cookie value as the key to their respective HttpSession objects. So in fact not only are the HttpSession objects always different and scoped at the application (servlet context) level but also, in practice, the JSESSIONID values have to be different. Is that correct?

2 If so, then why does the servlet specification use the wording:

The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts [...]

The only way I can imagine the above could be accomplished would be to have a way to hardcodedly provide the JSESSIONID value to use when a new session object is created? But I don't see an API for that.

3 Is there a way I can have some other cookies be shared among applications using the / path in the <session-config> XML element but not have the / path apply to the JSESSIONID cookie? In other words does the <session-config> apply to all cookies of an application or only the cookie used for session tracking? (JSESSIONID) ?

解决方案

Upon further experimentation and taking a cue from this answer it would appear that for the same JSESSIONID to be used for all web applications it is necessary to set the following attribute in context.xml:

<Context ... sessionCookiePath="/">

Either the Tomcat-wide context.xml or the WAR-specific context.xml will do. The <cookie-config><path> value configured in the WAR's web.xml is apparently ignored. So at this point even though I've addressed the question it is still not clear to me what the <cooke-config><path> element is supposed to serve for.

Regarding point 3 of my question I 've found that the way to set paths for other cookies is to programmatically create many of them, one for each path, and add them in the response object with the addCookie method. The configurations in web.xml or context.xml are appicable to other cookies beyond the session cookie.

这篇关于带有&lt; path&gt; /&lt; / path&gt;和JSESSIONID的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆