The continuation URL looks to only be stored if you arrived at the page by a call to PageMap#redirectToInterceptPage, which is called by RestartResponseAtInterceptPage exception. It's also stored in the session (or rather, the PageMap, which is stored in the session). So, yes, you would need a session to store that info into.
A suggestion might be to add the return URL to the sign in form as a hidden field, which you could redirect to in your onSubmit by throwing new RedirectException(urlFromForm). That doesn't sound like the cleanest solution. I'd have to think more to come up with something else. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 3, 2009 at 9:44 PM, Matt Welch <[email protected]> wrote: > > I'm trying to keep my app stateless wherever possible, especially on the > pages that serve merely as an introduction to the app but have no heavy > dynamic functionality. > > On many of these pages I have a sing-in panel. This sign-in panel contains > a > stateless username/password form. The onSubmit of the stateless form looks > like this: > > > @Override > protected void onSubmit() { > if (GVWebSession.get().authenticate(username, password)) { > if (!continueToOriginalDestination()){ > setResponsePage(getPage().getPageClass()); > } > } else { > error(getLocalizer().getString("signin.failed", > this)); > } > } > > > This doesn't seem to work. The behavior I want pretty common. I want the > same page displayed, but now with the user logged in and the sign-in form > replaced with a "welcome xxxx" message or something like that. What > actually > occurs is (from the users' point of view) nothing. The page is redisplayed > and the form comes back up. I can debug the form submission and I see that > the users is being properly authenticated. I assume I'm doing something > wrong with my setResponsePage() call. If I comment out that > setResponsPage() > call, the login works and the page is displayed correctly but I then have a > long, ugly URL. > > I happen to go to a non-stateless page and a session is created, and then > come back to a stateless page, this login procedure works correctly, so I > assume that my problem has something to do with their not being a session > created yet. That seems odd though, because one wouldn't think my situation > would be that unusual. > > Any suggestions? > -- > View this message in context: > http://www.nabble.com/Trying-to-stay-stateless-but-having-some-issues-tp22323101p22323101.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
