Restoring web session in struts2

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 parameter开发者_JAVA百科s 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.

---

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