会话在选项卡之间共享
我有 JAVA Web 应用程序，我需要停止在浏览器选项卡之间共享会话，这意味着
用户打开浏览器，登录到他的帐户并在同一浏览器的新选项卡中打开特定页面。根据默认设置，会话将共享到新选项卡，并且用户将自动登录到新选项卡。谁能告诉我如何阻止这种情况，这样我至少可以将其限制在几个敏感页面（如果不是整个应用程序）。
I have JAVA web application where I need to stop session being shared between browser tabs, meaning
User opens a browser, Logs into his account and opens a particular page in a new tab in the same browser. As per the default setting the session is shared to the new tab and the user is automatically logged-in to the new tab. Can anyone tell how this can be stopped so I can at least restrict this in few sensitive pages if not the entire application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常cookie用于会话处理。然后所有选项卡和浏览器窗口共享同一个会话。但是您可以将 servlet 容器配置为使用 URL 重写而不是 cookie。 （这是一个 Jetty 的示例。）
使用 URL 重写，会话只能通过包含会话 ID 的 URL 参数。因此，您的 Web 应用程序的每个内部 URL 都必须使用以下方法通过此参数进行增强
HttpServletResponse.encodeURL()。如果您正在使用像 Wicket 这样的 Web 框架，那么很可能这已经为您完成了。通过 URL 重写，可以在同一浏览器实例的不同窗口或选项卡中拥有多个独立会话。
更新：
为了回应反对票，我想澄清一下 URL 重写的不同行为：
假设网站的 URL 是 http://webapp.com。
Cookie：
在第一个浏览器选项卡中打开 http://webapp.com。
服务器创建一个会话并在响应中发送一个 cookie。
浏览器存储cookie。
然后在第二个浏览器选项卡中打开 http://webapp.com。浏览器将此 URL 与最近存储的 cookie 相关联，并将该 cookie 添加到请求中。
对于服务器来说，来自第一个或第二个浏览器选项卡的请求与来自同一会话的响应之间没有区别。有时这是期望的行为。
URL重写：
在第一个浏览器选项卡中打开 http://webapp.com。
服务器创建一个 ID 为 1 的会话，并将参数 jsessionid=1 添加到响应页面中的每个 URL。没有传输 cookie。
从第一个浏览器选项卡对同一 Web 应用程序的另一个页面的所有进一步请求都包含会话 ID（例如 1）。
然后从第二个浏览器选项卡打开 http://webapp.com。 区别在这里！ 由于请求中没有 cookie，也没有 jsessionid 参数，服务器会创建一个新的会话（即 ID 2），并将参数 jsessionid=2 添加到响应页面中包含的每个 URL 中。从现在起，来自第二个浏览器选项卡的所有后续请求都与会话 2 关联。
因此，您在同一浏览器中拥有两个独立的会话。
Usually cookies are used for session handling. Then all tabs and browser windows share the same session. But you can configure your servlet container to use URL rewrite instead of cookies. (Here is an example for Jetty.)
With URL rewrite the session is only identified via a URL parameter containing the session ID. So every internal URL of your web application has to be enhanced with this parameter using the method
HttpServletResponse.encodeURL(). If you are using a web framework like Wicket, chances are good that this is already done for you.With URL rewrite it is possible to have several indepedent sessions in different windows or tabs of the same browser instance.
Update:
In response to the downvote I want to make clear the different behaviour of URL rewriting:
Let's assume the website's URL is http://webapp.com.
Cookies:
Open http://webapp.com in the first browser tab.
The server creates a session and sends a cookie in the response.
The Browser stores the cookie.
Then open http://webapp.com in the second browser tab. The browser associates this URL with the recently stored cookie and adds the cookie to the request.
For the server there is no difference between requests from the first or second browser tab and responds from the same session. Sometimes this is the desired behaviour.
URL rewriting:
Open http://webapp.com in the first browser tab.
The server creates a session with ID 1 and adds the parameter jsessionid=1 to every URL in the response page. No cookie is transferred.
All further requests to another page of the same webapp from the first browser tab include the session ID (for exeample 1).
Then open http://webapp.com from the second browser tab. Here is the difference! Because there is no cookie and no jsessionid parameter in the request, the server creates a new session (i.e. ID 2) and adds parameter jsessionid=2 to every URL contained in the response page. From now on all subsequent requests from the second browser tab are associated with session 2.
So you have two independend sessions in the same browser.
如果您使用的是 javascript，我可以为您提供一种解决方法。
a) 登录屏幕中有一个隐藏参数，为该隐藏字段设置窗口名称
b)当你登录（提交请求）时，在action类中检查请求参数是否不为空并且等于登陆页面，这是一个有效的请求，意味着通过登录进入登陆页面，如果没有重定向到无效页面。
If you are using javascript i can provide you one work around.
a)Have one hidden parameter in login screen, set the windowname for that hidden field
b)when you are login (submiting the request) , in action class check if the request parameter is not null and it is equal to landing page, its a valid request, means comming to landing page by logining, if not redirect to invalid page.