You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Matt Welch <ma...@welchkin.net> on 2009/03/04 04:44:14 UTC
Trying to stay stateless but having some issues
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Trying to stay stateless but having some issues
Posted by Matt Welch <ma...@welchkin.net>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Trying to stay stateless but having some issues
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <ma...@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 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>