在struts2中恢复Web会话
我有一个网站和支付网关集成的经典场景，其中支付请求被发送到支付处理器，支付处理器在完成我在原始请求中传递给它的一些参数后回调我的应用程序。
在参数中，我们传递 jsessionid，并且我们期望当远程服务器向我们的服务器发出请求（通过客户浏览器重定向到我们的服务器）时，会话将与用于发送初始支付请求的会话相同。这种情况不会发生，我们有两个不同的会话，尽管支付处理器在向我们发出的请求中包含了我们原始的 jsessionid (https: //blabla/?jsessionid=something）。
我们应该如何在 struts2 中重新创建会话，因为唯一连接“旧”和“新”会话的是请求 URL 中的 jsessionid ？
有什么想法吗？这是否可能，或者当用户使用其数据输入表单从我们的服务器移至完全不同的支付处理器域时，“旧”会话数据是否会被删除？这可以解释我们无法重新创建会话的原因。
非常感谢您的回复。
I have a classical scenario of a website and payment gateway integration, where the request for payment is sent to payment processor, and the payment processor calls back my application once it's done with some parameters I passed to it in the original request.
Among parameters, we pass jsessionid and we expect that when the remote server makes request to our server (via customer browser redirect to our server) that the session will be the same as the session used to send the initial payment request. This does not happen, we have two different sessions, although the payment processor includes our original jsessionid in the request to us (https://blabla/?jsessionid=something).
How should we go about recreating a session in struts2, in the only thing that connects the 'OLD' and 'NEW' session is the jsessionid in the request URL?
Any ideas? Is this possible at all or is the 'OLD' session data deleted when the user moves away from our server onto a completely different domain of a payment processor with their data-entry form? This would explain our innability to recreate the session.
Thanks a lot for your replies.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许（我不确定）尝试从另一个网站将自己“重新绑定”到旧的 struts（servlet）会话并不是一个好的做法。
您希望用户从支付处理器返回您的 struts2 网站而不询问其凭据，这是可以理解的。但是，在高级意义上“保持会话处于活动状态”（从不需要重新验证的用户的角度来看），并不一定意味着您想要保留 struts-servlet 会话 活着，以便重新绑定到它。在我看来，这有点肮脏并且容易出现不安全问题 - 例如，不清楚（对于用户或开发人员来说）当用户位于支付站点时原始会话是打开还是关闭（考虑一下在支付网站中进行“注销”操作...这也会使用户从原始网站注销吗？）
我会选择以下场景之一：
1）当经过身份验证的用户单击支付网站的链接时，它会打开另一个窗口 - 有两个会话处于活动状态，他可以独立导航和关闭每个会话（第一个窗口只是提供了打开第二个会话的身份验证票证）。这是我在自己的家庭银行业务中经常看到的行为。
2）如果新的支付站点页面取代了以前的页面，则原始（servlet）会话将失效 - 但在新会话中，在支付站点中，放置了某种身份验证授权令牌，允许他返回到原始会话站点（可能包含一些特定于会话的数据）。但在这种情况下，将会有一个新的 servlet-struts2 会话。
基本上，我说过，（从概念上和有意地）考虑一个不存在的浏览器窗口的 servlet 会话处于活动状态（即它已被关闭或被另一个 web 应用程序的某些页面替换）是可疑的做法。
另请参见此处：http://nickcoblentz.blogspot。 com/2008/09/jsessionid-regenesis-in-struts-2.html
Perhaps (I'm not sure) it's not good practice, trying to "rebind" yourself to your old struts (servlet) session from another web site.
It's understandable that you want the user to return to your struts2 web-site from the payment-processor without asking for its credentials. But to "keep the session alive" in that high-level sense (from the point of view of the user who does not need to re-authenticate), does not necessarily implies that you want to keep the struts-servlet session alive, in order to rebind to it. This seems to me slightly dirty and prone to unsecurity - eg, it's not clear (nor for the user, nor for the developer) if the original session is open or closed at the moment when the user is in the payment site (think about a "logout" action while in the payment site ... would this also logout the user from the original site ?)
I'd opt for one of these scenarios:
1) When the authenticated user click the link to the payment site, it opens another window - there are two sessions active, he can navigate and close each one independently (the first one just gave a authentication ticket to open the second). That's the behaviour I usually see in my own home banking.
2) If the new payment site page replaces the previous, then the original (servlet) session is invalidated - But in the new session, in the payment site, is placed some sort of authentication-authorization token that allows him to return to the original site (perhaps with some session-specific data). But in this case there would be a new servlet-struts2 session.
Basically, I'd said it's dubious practice to (conceptually and intentionally) consider a servlet session alive for a browser window which is not alive (i.e. it has been closed or replaced by some page from another webapp).
See also here: http://nickcoblentz.blogspot.com/2008/09/jsessionid-regeneration-in-struts-2.html