Re: Trying to stay stateless but having some issues

2009-03-04 Thread Matt Welch


Jeremy Thomerson-5 wrote:
 
 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.
 
Thank you for the reply. I guess I'm a little surprised to run into this as
it seems like this would be a pretty common scenario for an application. I'm
certain willing to consider any approach. If forced, I can probably live
with the long, non-bookmarkable url after this login operation if I have to.

-- 
View this message in context: 
http://www.nabble.com/Trying-to-stay-stateless-but-having-some-issues-tp22323101p22344092.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Trying to stay stateless but having some issues

2009-03-03 Thread Jeremy Thomerson
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 matt...@welchkin.net 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  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: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org