You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jim Goodwin <so...@comcast.net> on 2011/03/10 18:36:08 UTC
Wicket in Action: problem with redirection
I'm a Wicket newbie, working my way through /Wicket in Action.
/I don't understand redirection too clearly yet, but there is
an example in the book which doesn't work right when I
try it and I'd like to ask if the book example code makes
sense to more experienced folks.
Page 271 Listing 11.3 line 4: The onSubmit() method calls
!continueToOriginalDestination().
Page 272 Listing 11.4 , new Link(...){ ... method onClick():
throws new RestartResponseAtInterceptPageException(signInPage)
How is this supposed to work?
Suppose the user is on the Home page, and the Home Page
has a UserPanel, and the user clicks on the "Sign In" link.
Then the link itself sets an intercept to the sign-in page
(that is how the link arranges to take you there, as far as I can
understand).
But then, when the user enters name/password and submits, and
the submit method calls continueToOriginalDestination(), it will
always succceed, and find the "original destination" to be the signIn
page, regardless of where it really originated (the Home Page, in
this case).
For a while my code was working like that: Signing in worked,
i.e. it did sign you in, but you were returned to a blank sign-in page.
(My code doesn't work like that just this minute, but that is only
because I've been enhancing it with other bugs.)
Can anyone explain how the book-example is supposed to work?
Thanks
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket in Action: problem with redirection
Posted by Martin Grigorov <mg...@apache.org>.
Better check the behavior with the quickstart with Wicket 1.4.16
1.5-M3 may had a bug.
On Fri, Mar 18, 2011 at 8:50 PM, Jim Pinkham <pi...@gmail.com> wrote:
> Martin,
>
> Thanks, no I hadn't seen that... but now I think this is just because I
> over-simplified the quickstart - it still doesn't explain why it was
> working
> properly up thru 1.5-M3 (using examples from wicket-auth-roles to have
> login link hander throw this restart exception, so if that's not a bug, I
> must be missing something else...
>
> So I've got my kludge fix for now, and it works in both the quickstart and
> my own app, so it'll get me along for a while.. I'm happy to assist
> further
> but feeling a bit past my level of experience.
>
> Thanks,
> -- Jim.
>
> On Fri, Mar 18, 2011 at 3:41 PM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > On Fri, Mar 18, 2011 at 8:39 PM, Jim Pinkham <pi...@gmail.com> wrote:
> >
> > > .. and I also attached a fairly ugly patched version of
> > >
> > > RestartResponseAtInterceptPageException
> > >
> > > that seem to work for me, but use at your own risk.
> > >
> > > Did you see Igor's response ?
> >
> >
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Wicket in Action: problem with redirection
Posted by Jim Pinkham <pi...@gmail.com>.
Martin,
Thanks, no I hadn't seen that... but now I think this is just because I
over-simplified the quickstart - it still doesn't explain why it was working
properly up thru 1.5-M3 (using examples from wicket-auth-roles to have
login link hander throw this restart exception, so if that's not a bug, I
must be missing something else...
So I've got my kludge fix for now, and it works in both the quickstart and
my own app, so it'll get me along for a while.. I'm happy to assist further
but feeling a bit past my level of experience.
Thanks,
-- Jim.
On Fri, Mar 18, 2011 at 3:41 PM, Martin Grigorov <mg...@apache.org>wrote:
> On Fri, Mar 18, 2011 at 8:39 PM, Jim Pinkham <pi...@gmail.com> wrote:
>
> > .. and I also attached a fairly ugly patched version of
> >
> > RestartResponseAtInterceptPageException
> >
> > that seem to work for me, but use at your own risk.
> >
> > Did you see Igor's response ?
>
>
Re: Wicket in Action: problem with redirection
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Mar 18, 2011 at 8:39 PM, Jim Pinkham <pi...@gmail.com> wrote:
> .. and I also attached a fairly ugly patched version of
>
> RestartResponseAtInterceptPageException
>
> that seem to work for me, but use at your own risk.
>
> Did you see Igor's response ?
> Hope this helps,
> -- Jim.
>
>
> On Thu, Mar 17, 2011 at 11:12 AM, Jim Pinkham <pi...@gmail.com> wrote:
>
>> OK, I just attached a quickstart (my first) - hope it helps with
>> resolution (soon).
>>
>>
>> On Wed, Mar 16, 2011 at 5:03 PM, Martin Grigorov <mg...@apache.org>wrote:
>>
>>> Thanks Jim,
>>>
>>> But without a quickstart it is hard to debug it.
>>> There is a ticket which sounds to be related to what you described:
>>> https://issues.apache.org/jira/browse/WICKET-3493
>>>
>>> On Wed, Mar 16, 2011 at 9:54 PM, Jim Pinkham <pi...@gmail.com> wrote:
>>>
>>> > FYI - rc2 still has this problem. It works OK on a
>>> BookmarkablePageLink
>>> > to
>>> > a page that implement IAuthorizationStrategy, but not on the new
>>> > Link<MyLoginPage> on a panel on my home page. After login is complete,
>>> the
>>> > link is hidden and replaced with a logout link, so the user gets an
>>> > AccessDenied page after login as they try to 'restart the response' to
>>> the
>>> > (wrong) onClick handler url for the now-invisible login link.
>>> >
>>> > Not sure when I'll get to making quickstart, but I thought I'd give at
>>> > least
>>> > this brief info for now.
>>> > Thanks,
>>> > -- Jim.
>>> >
>>> > On Wed, Mar 16, 2011 at 5:01 AM, Martin Grigorov <mgrigorov@apache.org
>>> > >wrote:
>>> >
>>> > > Try with RC2 and if it still fails please create a ticket with a
>>> > quickstart
>>> > >
>>> > > On Tue, Mar 15, 2011 at 11:27 PM, Jim Pinkham <pi...@gmail.com>
>>> > wrote:
>>> > >
>>> > > > I think I've got the same situation happening.
>>> > > >
>>> > > > It's a login link on my home page, whose onClick
>>> > > > uses the usual:
>>> > > > throw new RestartResponseAtInterceptPageException(
>>> > > > AuctionApplication.get().getSignInPageClass());
>>> > > >
>>> > > > I've stepped thru this a bit, and I find a problematic point in:
>>> > > > RestartResponseAtInterceptPageException.InterceptData.set() where
>>> it
>>> > > > captures what I think is supposed to be the home page url, which it
>>> is
>>> > > > saving as follows:
>>> > > > ...
>>> > > > data.originalUrl = request.getOriginalUrl();
>>> > > >
>>> > > > However, in my debugger, this is instead the Url of the link:
>>> > > >
>>> > > >
>>> > >
>>> >
>>> http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
>>> > > >
>>> > > > If I manually change it in the debugger to just my home page Url,
>>> it
>>> > > seems
>>> > > > to work fine.
>>> > > >
>>> > > > This was working last for me in 1.5-M3, and now in 1.5-RC1 it
>>> appears
>>> > to
>>> > > > have broken.
>>> > > >
>>> > > > Hope this helps narrow the search...
>>> > > >
>>> > > > Thanks,
>>> > > > -- Jim.
>>> > > >
>>> > > > On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <
>>> > > > jeremy@wickettraining.com
>>> > > > > wrote:
>>> > > >
>>> > > > > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <
>>> sophinken@comcast.net
>>> > >
>>> > > > > wrote:
>>> > > > >
>>> > > > > > I'm a Wicket newbie, working my way through /Wicket in Action.
>>> > > > > >
>>> > > > > > /I don't understand redirection too clearly yet, but there is
>>> > > > > > an example in the book which doesn't work right when I
>>> > > > > > try it and I'd like to ask if the book example code makes
>>> > > > > > sense to more experienced folks.
>>> > > > > >
>>> > > > > > Page 271 Listing 11.3 line 4: The onSubmit() method calls
>>> > > > > > !continueToOriginalDestination().
>>> > > > > >
>>> > > > >
>>> > > > > continueToOriginalDestination() lets the user continue on to the
>>> > place
>>> > > > they
>>> > > > > were going before being interrupted by the security mechanism if
>>> they
>>> > > > > aren't
>>> > > > > logged in. i.e:
>>> > > > >
>>> > > > > user on home page
>>> > > > > user clicks "restricted page" link
>>> > > > > security strategy says "can't go there without being logged in as
>>> X",
>>> > > > > redirects user to login page
>>> > > > > user logs in, and continueToOriginalDestination() redirects to
>>> > > > "restricted
>>> > > > > page" (original dest) and returns true.
>>> > > > >
>>> > > > > another example:
>>> > > > > user clicks bookmarked link in a new tab in their browser to
>>> login
>>> > page
>>> > > > (or
>>> > > > > goes to unrestricted home page and clicks link for login page)
>>> > > > > user logs in, and continueToOriginalDestination() can't redirect
>>> them
>>> > > > > anywhere, because there is no "original destination" that was
>>> > > interrupted
>>> > > > >
>>> > > > > Page 272 Listing 11.4 , new Link(...){ ... method onClick():
>>> > > > > > throws new RestartResponseAtInterceptPageException(signInPage)
>>> > > > > >
>>> > > > >
>>> > > > > This is a way to stop processing at ANY point in your application
>>> and
>>> > > > > redirect the user to a certain page.
>>> > > > >
>>> > > > >
>>> > > > > > How is this supposed to work?
>>> > > > > >
>>> > > > > > Suppose the user is on the Home page, and the Home Page
>>> > > > > > has a UserPanel, and the user clicks on the "Sign In" link.
>>> > > > > > Then the link itself sets an intercept to the sign-in page
>>> > > > > > (that is how the link arranges to take you there, as far as I
>>> can
>>> > > > > > understand).
>>> > > > > >
>>> > > > > > But then, when the user enters name/password and submits, and
>>> > > > > > the submit method calls continueToOriginalDestination(), it
>>> will
>>> > > > > > always succceed, and find the "original destination" to be the
>>> > signIn
>>> > > > > > page, regardless of where it really originated (the Home Page,
>>> in
>>> > > > > > this case).
>>> > > > > >
>>> > > > >
>>> > > > > You're a bit confused by "original" and "destination". Since the
>>> > user
>>> > > > > clicked the "signin page" link, the *destination* was the signin
>>> page
>>> > -
>>> > > > > which is unrestricted, so the continueToOriginalDestination()
>>> method
>>> > > can
>>> > > > > not
>>> > > > > redirect them anywhere, and thus returns false. You now need to
>>> > > redirect
>>> > > > > them somewhere manually or the signin page will re-render.
>>> > > > >
>>> > > > > The *origin* was the home page - but that doesn't matter. Don't
>>> be
>>> > > > thrown
>>> > > > > off by "original" (destination) and "origin" - which are two
>>> > different
>>> > > > > things. :)
>>> > > > >
>>> > > > > For a while my code was working like that: Signing in worked,
>>> > > > > > i.e. it did sign you in, but you were returned to a blank
>>> sign-in
>>> > > page.
>>> > > > > > (My code doesn't work like that just this minute, but that is
>>> only
>>> > > > > > because I've been enhancing it with other bugs.)
>>> > > > > >
>>> > > > > > Can anyone explain how the book-example is supposed to work?
>>> > > > > >
>>> > > > > > Thanks
>>> > > > > > Jim
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > Jeremy Thomerson
>>> > > > > http://wickettraining.com
>>> > > > > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>>> > > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Martin Grigorov
>>> > > jWeekend
>>> > > Training, Consulting, Development
>>> > > http://jWeekend.com <http://jweekend.com/>
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com <http://jweekend.com/>
>>>
>>
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Wicket in Action: problem with redirection
Posted by Jim Pinkham <pi...@gmail.com>.
OK, I just attached a quickstart (my first) - hope it helps with resolution
(soon).
On Wed, Mar 16, 2011 at 5:03 PM, Martin Grigorov <mg...@apache.org>wrote:
> Thanks Jim,
>
> But without a quickstart it is hard to debug it.
> There is a ticket which sounds to be related to what you described:
> https://issues.apache.org/jira/browse/WICKET-3493
>
> On Wed, Mar 16, 2011 at 9:54 PM, Jim Pinkham <pi...@gmail.com> wrote:
>
> > FYI - rc2 still has this problem. It works OK on a BookmarkablePageLink
> > to
> > a page that implement IAuthorizationStrategy, but not on the new
> > Link<MyLoginPage> on a panel on my home page. After login is complete,
> the
> > link is hidden and replaced with a logout link, so the user gets an
> > AccessDenied page after login as they try to 'restart the response' to
> the
> > (wrong) onClick handler url for the now-invisible login link.
> >
> > Not sure when I'll get to making quickstart, but I thought I'd give at
> > least
> > this brief info for now.
> > Thanks,
> > -- Jim.
> >
> > On Wed, Mar 16, 2011 at 5:01 AM, Martin Grigorov <mgrigorov@apache.org
> > >wrote:
> >
> > > Try with RC2 and if it still fails please create a ticket with a
> > quickstart
> > >
> > > On Tue, Mar 15, 2011 at 11:27 PM, Jim Pinkham <pi...@gmail.com>
> > wrote:
> > >
> > > > I think I've got the same situation happening.
> > > >
> > > > It's a login link on my home page, whose onClick
> > > > uses the usual:
> > > > throw new RestartResponseAtInterceptPageException(
> > > > AuctionApplication.get().getSignInPageClass());
> > > >
> > > > I've stepped thru this a bit, and I find a problematic point in:
> > > > RestartResponseAtInterceptPageException.InterceptData.set() where it
> > > > captures what I think is supposed to be the home page url, which it
> is
> > > > saving as follows:
> > > > ...
> > > > data.originalUrl = request.getOriginalUrl();
> > > >
> > > > However, in my debugger, this is instead the Url of the link:
> > > >
> > > >
> > >
> >
> http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
> > > >
> > > > If I manually change it in the debugger to just my home page Url, it
> > > seems
> > > > to work fine.
> > > >
> > > > This was working last for me in 1.5-M3, and now in 1.5-RC1 it appears
> > to
> > > > have broken.
> > > >
> > > > Hope this helps narrow the search...
> > > >
> > > > Thanks,
> > > > -- Jim.
> > > >
> > > > On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <
> > > > jeremy@wickettraining.com
> > > > > wrote:
> > > >
> > > > > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <
> sophinken@comcast.net
> > >
> > > > > wrote:
> > > > >
> > > > > > I'm a Wicket newbie, working my way through /Wicket in Action.
> > > > > >
> > > > > > /I don't understand redirection too clearly yet, but there is
> > > > > > an example in the book which doesn't work right when I
> > > > > > try it and I'd like to ask if the book example code makes
> > > > > > sense to more experienced folks.
> > > > > >
> > > > > > Page 271 Listing 11.3 line 4: The onSubmit() method calls
> > > > > > !continueToOriginalDestination().
> > > > > >
> > > > >
> > > > > continueToOriginalDestination() lets the user continue on to the
> > place
> > > > they
> > > > > were going before being interrupted by the security mechanism if
> they
> > > > > aren't
> > > > > logged in. i.e:
> > > > >
> > > > > user on home page
> > > > > user clicks "restricted page" link
> > > > > security strategy says "can't go there without being logged in as
> X",
> > > > > redirects user to login page
> > > > > user logs in, and continueToOriginalDestination() redirects to
> > > > "restricted
> > > > > page" (original dest) and returns true.
> > > > >
> > > > > another example:
> > > > > user clicks bookmarked link in a new tab in their browser to login
> > page
> > > > (or
> > > > > goes to unrestricted home page and clicks link for login page)
> > > > > user logs in, and continueToOriginalDestination() can't redirect
> them
> > > > > anywhere, because there is no "original destination" that was
> > > interrupted
> > > > >
> > > > > Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> > > > > > throws new RestartResponseAtInterceptPageException(signInPage)
> > > > > >
> > > > >
> > > > > This is a way to stop processing at ANY point in your application
> and
> > > > > redirect the user to a certain page.
> > > > >
> > > > >
> > > > > > How is this supposed to work?
> > > > > >
> > > > > > Suppose the user is on the Home page, and the Home Page
> > > > > > has a UserPanel, and the user clicks on the "Sign In" link.
> > > > > > Then the link itself sets an intercept to the sign-in page
> > > > > > (that is how the link arranges to take you there, as far as I can
> > > > > > understand).
> > > > > >
> > > > > > But then, when the user enters name/password and submits, and
> > > > > > the submit method calls continueToOriginalDestination(), it will
> > > > > > always succceed, and find the "original destination" to be the
> > signIn
> > > > > > page, regardless of where it really originated (the Home Page, in
> > > > > > this case).
> > > > > >
> > > > >
> > > > > You're a bit confused by "original" and "destination". Since the
> > user
> > > > > clicked the "signin page" link, the *destination* was the signin
> page
> > -
> > > > > which is unrestricted, so the continueToOriginalDestination()
> method
> > > can
> > > > > not
> > > > > redirect them anywhere, and thus returns false. You now need to
> > > redirect
> > > > > them somewhere manually or the signin page will re-render.
> > > > >
> > > > > The *origin* was the home page - but that doesn't matter. Don't be
> > > > thrown
> > > > > off by "original" (destination) and "origin" - which are two
> > different
> > > > > things. :)
> > > > >
> > > > > For a while my code was working like that: Signing in worked,
> > > > > > i.e. it did sign you in, but you were returned to a blank sign-in
> > > page.
> > > > > > (My code doesn't work like that just this minute, but that is
> only
> > > > > > because I've been enhancing it with other bugs.)
> > > > > >
> > > > > > Can anyone explain how the book-example is supposed to work?
> > > > > >
> > > > > > Thanks
> > > > > > Jim
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeremy Thomerson
> > > > > http://wickettraining.com
> > > > > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Martin Grigorov
> > > jWeekend
> > > Training, Consulting, Development
> > > http://jWeekend.com <http://jweekend.com/>
> > >
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>
Re: Wicket in Action: problem with redirection
Posted by Martin Grigorov <mg...@apache.org>.
Thanks Jim,
But without a quickstart it is hard to debug it.
There is a ticket which sounds to be related to what you described:
https://issues.apache.org/jira/browse/WICKET-3493
On Wed, Mar 16, 2011 at 9:54 PM, Jim Pinkham <pi...@gmail.com> wrote:
> FYI - rc2 still has this problem. It works OK on a BookmarkablePageLink
> to
> a page that implement IAuthorizationStrategy, but not on the new
> Link<MyLoginPage> on a panel on my home page. After login is complete, the
> link is hidden and replaced with a logout link, so the user gets an
> AccessDenied page after login as they try to 'restart the response' to the
> (wrong) onClick handler url for the now-invisible login link.
>
> Not sure when I'll get to making quickstart, but I thought I'd give at
> least
> this brief info for now.
> Thanks,
> -- Jim.
>
> On Wed, Mar 16, 2011 at 5:01 AM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > Try with RC2 and if it still fails please create a ticket with a
> quickstart
> >
> > On Tue, Mar 15, 2011 at 11:27 PM, Jim Pinkham <pi...@gmail.com>
> wrote:
> >
> > > I think I've got the same situation happening.
> > >
> > > It's a login link on my home page, whose onClick
> > > uses the usual:
> > > throw new RestartResponseAtInterceptPageException(
> > > AuctionApplication.get().getSignInPageClass());
> > >
> > > I've stepped thru this a bit, and I find a problematic point in:
> > > RestartResponseAtInterceptPageException.InterceptData.set() where it
> > > captures what I think is supposed to be the home page url, which it is
> > > saving as follows:
> > > ...
> > > data.originalUrl = request.getOriginalUrl();
> > >
> > > However, in my debugger, this is instead the Url of the link:
> > >
> > >
> >
> http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
> > >
> > > If I manually change it in the debugger to just my home page Url, it
> > seems
> > > to work fine.
> > >
> > > This was working last for me in 1.5-M3, and now in 1.5-RC1 it appears
> to
> > > have broken.
> > >
> > > Hope this helps narrow the search...
> > >
> > > Thanks,
> > > -- Jim.
> > >
> > > On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <
> > > jeremy@wickettraining.com
> > > > wrote:
> > >
> > > > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <sophinken@comcast.net
> >
> > > > wrote:
> > > >
> > > > > I'm a Wicket newbie, working my way through /Wicket in Action.
> > > > >
> > > > > /I don't understand redirection too clearly yet, but there is
> > > > > an example in the book which doesn't work right when I
> > > > > try it and I'd like to ask if the book example code makes
> > > > > sense to more experienced folks.
> > > > >
> > > > > Page 271 Listing 11.3 line 4: The onSubmit() method calls
> > > > > !continueToOriginalDestination().
> > > > >
> > > >
> > > > continueToOriginalDestination() lets the user continue on to the
> place
> > > they
> > > > were going before being interrupted by the security mechanism if they
> > > > aren't
> > > > logged in. i.e:
> > > >
> > > > user on home page
> > > > user clicks "restricted page" link
> > > > security strategy says "can't go there without being logged in as X",
> > > > redirects user to login page
> > > > user logs in, and continueToOriginalDestination() redirects to
> > > "restricted
> > > > page" (original dest) and returns true.
> > > >
> > > > another example:
> > > > user clicks bookmarked link in a new tab in their browser to login
> page
> > > (or
> > > > goes to unrestricted home page and clicks link for login page)
> > > > user logs in, and continueToOriginalDestination() can't redirect them
> > > > anywhere, because there is no "original destination" that was
> > interrupted
> > > >
> > > > Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> > > > > throws new RestartResponseAtInterceptPageException(signInPage)
> > > > >
> > > >
> > > > This is a way to stop processing at ANY point in your application and
> > > > redirect the user to a certain page.
> > > >
> > > >
> > > > > How is this supposed to work?
> > > > >
> > > > > Suppose the user is on the Home page, and the Home Page
> > > > > has a UserPanel, and the user clicks on the "Sign In" link.
> > > > > Then the link itself sets an intercept to the sign-in page
> > > > > (that is how the link arranges to take you there, as far as I can
> > > > > understand).
> > > > >
> > > > > But then, when the user enters name/password and submits, and
> > > > > the submit method calls continueToOriginalDestination(), it will
> > > > > always succceed, and find the "original destination" to be the
> signIn
> > > > > page, regardless of where it really originated (the Home Page, in
> > > > > this case).
> > > > >
> > > >
> > > > You're a bit confused by "original" and "destination". Since the
> user
> > > > clicked the "signin page" link, the *destination* was the signin page
> -
> > > > which is unrestricted, so the continueToOriginalDestination() method
> > can
> > > > not
> > > > redirect them anywhere, and thus returns false. You now need to
> > redirect
> > > > them somewhere manually or the signin page will re-render.
> > > >
> > > > The *origin* was the home page - but that doesn't matter. Don't be
> > > thrown
> > > > off by "original" (destination) and "origin" - which are two
> different
> > > > things. :)
> > > >
> > > > For a while my code was working like that: Signing in worked,
> > > > > i.e. it did sign you in, but you were returned to a blank sign-in
> > page.
> > > > > (My code doesn't work like that just this minute, but that is only
> > > > > because I've been enhancing it with other bugs.)
> > > > >
> > > > > Can anyone explain how the book-example is supposed to work?
> > > > >
> > > > > Thanks
> > > > > Jim
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeremy Thomerson
> > > > http://wickettraining.com
> > > > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> > > >
> > >
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com <http://jweekend.com/>
> >
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Wicket in Action: problem with redirection
Posted by Jim Pinkham <pi...@gmail.com>.
FYI - rc2 still has this problem. It works OK on a BookmarkablePageLink to
a page that implement IAuthorizationStrategy, but not on the new
Link<MyLoginPage> on a panel on my home page. After login is complete, the
link is hidden and replaced with a logout link, so the user gets an
AccessDenied page after login as they try to 'restart the response' to the
(wrong) onClick handler url for the now-invisible login link.
Not sure when I'll get to making quickstart, but I thought I'd give at least
this brief info for now.
Thanks,
-- Jim.
On Wed, Mar 16, 2011 at 5:01 AM, Martin Grigorov <mg...@apache.org>wrote:
> Try with RC2 and if it still fails please create a ticket with a quickstart
>
> On Tue, Mar 15, 2011 at 11:27 PM, Jim Pinkham <pi...@gmail.com> wrote:
>
> > I think I've got the same situation happening.
> >
> > It's a login link on my home page, whose onClick
> > uses the usual:
> > throw new RestartResponseAtInterceptPageException(
> > AuctionApplication.get().getSignInPageClass());
> >
> > I've stepped thru this a bit, and I find a problematic point in:
> > RestartResponseAtInterceptPageException.InterceptData.set() where it
> > captures what I think is supposed to be the home page url, which it is
> > saving as follows:
> > ...
> > data.originalUrl = request.getOriginalUrl();
> >
> > However, in my debugger, this is instead the Url of the link:
> >
> >
> http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
> >
> > If I manually change it in the debugger to just my home page Url, it
> seems
> > to work fine.
> >
> > This was working last for me in 1.5-M3, and now in 1.5-RC1 it appears to
> > have broken.
> >
> > Hope this helps narrow the search...
> >
> > Thanks,
> > -- Jim.
> >
> > On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <
> > jeremy@wickettraining.com
> > > wrote:
> >
> > > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <so...@comcast.net>
> > > wrote:
> > >
> > > > I'm a Wicket newbie, working my way through /Wicket in Action.
> > > >
> > > > /I don't understand redirection too clearly yet, but there is
> > > > an example in the book which doesn't work right when I
> > > > try it and I'd like to ask if the book example code makes
> > > > sense to more experienced folks.
> > > >
> > > > Page 271 Listing 11.3 line 4: The onSubmit() method calls
> > > > !continueToOriginalDestination().
> > > >
> > >
> > > continueToOriginalDestination() lets the user continue on to the place
> > they
> > > were going before being interrupted by the security mechanism if they
> > > aren't
> > > logged in. i.e:
> > >
> > > user on home page
> > > user clicks "restricted page" link
> > > security strategy says "can't go there without being logged in as X",
> > > redirects user to login page
> > > user logs in, and continueToOriginalDestination() redirects to
> > "restricted
> > > page" (original dest) and returns true.
> > >
> > > another example:
> > > user clicks bookmarked link in a new tab in their browser to login page
> > (or
> > > goes to unrestricted home page and clicks link for login page)
> > > user logs in, and continueToOriginalDestination() can't redirect them
> > > anywhere, because there is no "original destination" that was
> interrupted
> > >
> > > Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> > > > throws new RestartResponseAtInterceptPageException(signInPage)
> > > >
> > >
> > > This is a way to stop processing at ANY point in your application and
> > > redirect the user to a certain page.
> > >
> > >
> > > > How is this supposed to work?
> > > >
> > > > Suppose the user is on the Home page, and the Home Page
> > > > has a UserPanel, and the user clicks on the "Sign In" link.
> > > > Then the link itself sets an intercept to the sign-in page
> > > > (that is how the link arranges to take you there, as far as I can
> > > > understand).
> > > >
> > > > But then, when the user enters name/password and submits, and
> > > > the submit method calls continueToOriginalDestination(), it will
> > > > always succceed, and find the "original destination" to be the signIn
> > > > page, regardless of where it really originated (the Home Page, in
> > > > this case).
> > > >
> > >
> > > You're a bit confused by "original" and "destination". Since the user
> > > clicked the "signin page" link, the *destination* was the signin page -
> > > which is unrestricted, so the continueToOriginalDestination() method
> can
> > > not
> > > redirect them anywhere, and thus returns false. You now need to
> redirect
> > > them somewhere manually or the signin page will re-render.
> > >
> > > The *origin* was the home page - but that doesn't matter. Don't be
> > thrown
> > > off by "original" (destination) and "origin" - which are two different
> > > things. :)
> > >
> > > For a while my code was working like that: Signing in worked,
> > > > i.e. it did sign you in, but you were returned to a blank sign-in
> page.
> > > > (My code doesn't work like that just this minute, but that is only
> > > > because I've been enhancing it with other bugs.)
> > > >
> > > > Can anyone explain how the book-example is supposed to work?
> > > >
> > > > Thanks
> > > > Jim
> > > >
> > >
> > >
> > > --
> > > Jeremy Thomerson
> > > http://wickettraining.com
> > > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> > >
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>
Re: Wicket in Action: problem with redirection
Posted by Martin Grigorov <mg...@apache.org>.
Try with RC2 and if it still fails please create a ticket with a quickstart
On Tue, Mar 15, 2011 at 11:27 PM, Jim Pinkham <pi...@gmail.com> wrote:
> I think I've got the same situation happening.
>
> It's a login link on my home page, whose onClick
> uses the usual:
> throw new RestartResponseAtInterceptPageException(
> AuctionApplication.get().getSignInPageClass());
>
> I've stepped thru this a bit, and I find a problematic point in:
> RestartResponseAtInterceptPageException.InterceptData.set() where it
> captures what I think is supposed to be the home page url, which it is
> saving as follows:
> ...
> data.originalUrl = request.getOriginalUrl();
>
> However, in my debugger, this is instead the Url of the link:
>
> http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
>
> If I manually change it in the debugger to just my home page Url, it seems
> to work fine.
>
> This was working last for me in 1.5-M3, and now in 1.5-RC1 it appears to
> have broken.
>
> Hope this helps narrow the search...
>
> Thanks,
> -- Jim.
>
> On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <
> jeremy@wickettraining.com
> > wrote:
>
> > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <so...@comcast.net>
> > wrote:
> >
> > > I'm a Wicket newbie, working my way through /Wicket in Action.
> > >
> > > /I don't understand redirection too clearly yet, but there is
> > > an example in the book which doesn't work right when I
> > > try it and I'd like to ask if the book example code makes
> > > sense to more experienced folks.
> > >
> > > Page 271 Listing 11.3 line 4: The onSubmit() method calls
> > > !continueToOriginalDestination().
> > >
> >
> > continueToOriginalDestination() lets the user continue on to the place
> they
> > were going before being interrupted by the security mechanism if they
> > aren't
> > logged in. i.e:
> >
> > user on home page
> > user clicks "restricted page" link
> > security strategy says "can't go there without being logged in as X",
> > redirects user to login page
> > user logs in, and continueToOriginalDestination() redirects to
> "restricted
> > page" (original dest) and returns true.
> >
> > another example:
> > user clicks bookmarked link in a new tab in their browser to login page
> (or
> > goes to unrestricted home page and clicks link for login page)
> > user logs in, and continueToOriginalDestination() can't redirect them
> > anywhere, because there is no "original destination" that was interrupted
> >
> > Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> > > throws new RestartResponseAtInterceptPageException(signInPage)
> > >
> >
> > This is a way to stop processing at ANY point in your application and
> > redirect the user to a certain page.
> >
> >
> > > How is this supposed to work?
> > >
> > > Suppose the user is on the Home page, and the Home Page
> > > has a UserPanel, and the user clicks on the "Sign In" link.
> > > Then the link itself sets an intercept to the sign-in page
> > > (that is how the link arranges to take you there, as far as I can
> > > understand).
> > >
> > > But then, when the user enters name/password and submits, and
> > > the submit method calls continueToOriginalDestination(), it will
> > > always succceed, and find the "original destination" to be the signIn
> > > page, regardless of where it really originated (the Home Page, in
> > > this case).
> > >
> >
> > You're a bit confused by "original" and "destination". Since the user
> > clicked the "signin page" link, the *destination* was the signin page -
> > which is unrestricted, so the continueToOriginalDestination() method can
> > not
> > redirect them anywhere, and thus returns false. You now need to redirect
> > them somewhere manually or the signin page will re-render.
> >
> > The *origin* was the home page - but that doesn't matter. Don't be
> thrown
> > off by "original" (destination) and "origin" - which are two different
> > things. :)
> >
> > For a while my code was working like that: Signing in worked,
> > > i.e. it did sign you in, but you were returned to a blank sign-in page.
> > > (My code doesn't work like that just this minute, but that is only
> > > because I've been enhancing it with other bugs.)
> > >
> > > Can anyone explain how the book-example is supposed to work?
> > >
> > > Thanks
> > > Jim
> > >
> >
> >
> > --
> > Jeremy Thomerson
> > http://wickettraining.com
> > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> >
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Wicket in Action: problem with redirection
Posted by Jim Pinkham <pi...@gmail.com>.
I think I've got the same situation happening.
It's a login link on my home page, whose onClick
uses the usual:
throw new RestartResponseAtInterceptPageException(
AuctionApplication.get().getSignInPageClass());
I've stepped thru this a bit, and I find a problematic point in:
RestartResponseAtInterceptPageException.InterceptData.set() where it
captures what I think is supposed to be the home page url, which it is
saving as follows:
...
data.originalUrl = request.getOriginalUrl();
However, in my debugger, this is instead the Url of the link:
http://localhost:8080/myapp/wicket/page?0-1.ILinkListener-userPanel-signIn
If I manually change it in the debugger to just my home page Url, it seems
to work fine.
This was working last for me in 1.5-M3, and now in 1.5-RC1 it appears to
have broken.
Hope this helps narrow the search...
Thanks,
-- Jim.
On Thu, Mar 10, 2011 at 1:50 PM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <so...@comcast.net>
> wrote:
>
> > I'm a Wicket newbie, working my way through /Wicket in Action.
> >
> > /I don't understand redirection too clearly yet, but there is
> > an example in the book which doesn't work right when I
> > try it and I'd like to ask if the book example code makes
> > sense to more experienced folks.
> >
> > Page 271 Listing 11.3 line 4: The onSubmit() method calls
> > !continueToOriginalDestination().
> >
>
> continueToOriginalDestination() lets the user continue on to the place they
> were going before being interrupted by the security mechanism if they
> aren't
> logged in. i.e:
>
> user on home page
> user clicks "restricted page" link
> security strategy says "can't go there without being logged in as X",
> redirects user to login page
> user logs in, and continueToOriginalDestination() redirects to "restricted
> page" (original dest) and returns true.
>
> another example:
> user clicks bookmarked link in a new tab in their browser to login page (or
> goes to unrestricted home page and clicks link for login page)
> user logs in, and continueToOriginalDestination() can't redirect them
> anywhere, because there is no "original destination" that was interrupted
>
> Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> > throws new RestartResponseAtInterceptPageException(signInPage)
> >
>
> This is a way to stop processing at ANY point in your application and
> redirect the user to a certain page.
>
>
> > How is this supposed to work?
> >
> > Suppose the user is on the Home page, and the Home Page
> > has a UserPanel, and the user clicks on the "Sign In" link.
> > Then the link itself sets an intercept to the sign-in page
> > (that is how the link arranges to take you there, as far as I can
> > understand).
> >
> > But then, when the user enters name/password and submits, and
> > the submit method calls continueToOriginalDestination(), it will
> > always succceed, and find the "original destination" to be the signIn
> > page, regardless of where it really originated (the Home Page, in
> > this case).
> >
>
> You're a bit confused by "original" and "destination". Since the user
> clicked the "signin page" link, the *destination* was the signin page -
> which is unrestricted, so the continueToOriginalDestination() method can
> not
> redirect them anywhere, and thus returns false. You now need to redirect
> them somewhere manually or the signin page will re-render.
>
> The *origin* was the home page - but that doesn't matter. Don't be thrown
> off by "original" (destination) and "origin" - which are two different
> things. :)
>
> For a while my code was working like that: Signing in worked,
> > i.e. it did sign you in, but you were returned to a blank sign-in page.
> > (My code doesn't work like that just this minute, but that is only
> > because I've been enhancing it with other bugs.)
> >
> > Can anyone explain how the book-example is supposed to work?
> >
> > Thanks
> > Jim
> >
>
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>
Re: Wicket in Action: problem with redirection
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin <so...@comcast.net> wrote:
> I'm a Wicket newbie, working my way through /Wicket in Action.
>
> /I don't understand redirection too clearly yet, but there is
> an example in the book which doesn't work right when I
> try it and I'd like to ask if the book example code makes
> sense to more experienced folks.
>
> Page 271 Listing 11.3 line 4: The onSubmit() method calls
> !continueToOriginalDestination().
>
continueToOriginalDestination() lets the user continue on to the place they
were going before being interrupted by the security mechanism if they aren't
logged in. i.e:
user on home page
user clicks "restricted page" link
security strategy says "can't go there without being logged in as X",
redirects user to login page
user logs in, and continueToOriginalDestination() redirects to "restricted
page" (original dest) and returns true.
another example:
user clicks bookmarked link in a new tab in their browser to login page (or
goes to unrestricted home page and clicks link for login page)
user logs in, and continueToOriginalDestination() can't redirect them
anywhere, because there is no "original destination" that was interrupted
Page 272 Listing 11.4 , new Link(...){ ... method onClick():
> throws new RestartResponseAtInterceptPageException(signInPage)
>
This is a way to stop processing at ANY point in your application and
redirect the user to a certain page.
> How is this supposed to work?
>
> Suppose the user is on the Home page, and the Home Page
> has a UserPanel, and the user clicks on the "Sign In" link.
> Then the link itself sets an intercept to the sign-in page
> (that is how the link arranges to take you there, as far as I can
> understand).
>
> But then, when the user enters name/password and submits, and
> the submit method calls continueToOriginalDestination(), it will
> always succceed, and find the "original destination" to be the signIn
> page, regardless of where it really originated (the Home Page, in
> this case).
>
You're a bit confused by "original" and "destination". Since the user
clicked the "signin page" link, the *destination* was the signin page -
which is unrestricted, so the continueToOriginalDestination() method can not
redirect them anywhere, and thus returns false. You now need to redirect
them somewhere manually or the signin page will re-render.
The *origin* was the home page - but that doesn't matter. Don't be thrown
off by "original" (destination) and "origin" - which are two different
things. :)
For a while my code was working like that: Signing in worked,
> i.e. it did sign you in, but you were returned to a blank sign-in page.
> (My code doesn't work like that just this minute, but that is only
> because I've been enhancing it with other bugs.)
>
> Can anyone explain how the book-example is supposed to work?
>
> Thanks
> Jim
>
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*