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/> >
