> What exactly do you want to achieve, from the user > perspective? Yeah... didn't explain this well.
Here's the thread in context: http://www.nabble.com/Associating-a-request-to-a-Session-td19641227.html I am trying to get OpenID authentication to work in Wicket. The related part on my original question is this: > I am forwarding a request to a third party server (OpenId > Provider), so I guess it's normal that Wicket thinks it's > not part of the same session... Basically, to authenticate the user, I throw a RestartResponseException( OpenIdSignInPage.class ); The user enters her OpenID, as the relying party, I forward the request to the OpenID Provider (OP), and the OP sends me back a reply with an authentication token. What the user sees is: 1. Try to access protected page 2. Redirect to sign in page 3. Redirect to OP site (where authentication occurs) 4. Redirect again back to original destination The problem is that 4 ends up being a different Session from 1, for reasons mentioned previously. Ideally, just like the "normal" sign in procedure, if we take the above as one single "AUTH" step, the user should see: A. Try to perform task B. Interrupt to AUTH C. Continue with original request A -> C should normally be in the same Session, just like the "normal" sign in does. > Maybe you could have your own token in the URL by using a > suitable url encoding strategy, and store the data you want > to restore in the database. Possible, but ideally, I'd like the OpenID login to work just like a "normal" login, as described above. Cheers, =dml --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
