On Fri, Mar 18, 2011 at 8:39 PM, Jim Pinkham <pinkh...@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 <pinkh...@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 <mgrigo...@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 <pinkh...@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 <mgrigo...@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 <pinkh...@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 < >>> > > > jer...@wickettraining.com >>> > > > > wrote: >>> > > > >>> > > > > On Thu, Mar 10, 2011 at 12:36 PM, Jim Goodwin < >>> sophin...@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/>
