Constructors take vararg of Component? (Enhancement RFC)
Greetings all, I was wondering what Wicket users & devs might thing of a possible API change for a future version (maybe Wicket 7?) of including a varargs array of Component as the final parameter of all of the various MarkupContainer subclasses? I find myself doing things like these a lot: pnlNoRsvp = new WebMarkupContainer("pnlNoRsvp"); pnlRsvp = new StatusPanel("pnlRsvp"); pnlConfirm = new ConfirmPanel("pnlConfirm"); pnlRsvpRules = new RsvpRulesPanel("pnlRsvpRules"); RsvpPage.this.add( new Label("event.title"), new CssFeedbackPanel("feedback"), new Form("frmRsvp", cpm) { { add(pnlNoRsvp, pnlRsvp, pnlConfirm); } }, pnlRsvpRules ); -- or -- Form frmRsvp = new Form("frmRsvp", cpm); frmRsvp.add(pnlNoRsvp, pnlRsvp, pnlConfirm); RsvpPage.this.add( new Label("event.title"), new CssFeedbackPanel("feedback"), frmRsvp, pnlRsvpRules ); -- If Form and the various other Wicket MarkupContainer's had constructors with Component... as their final parameter, it would be possible to do something like: RsvpPage.this.add( new Label("event.title"), new CssFeedbackPanel("feedback"), new Form("frmRsvp", cpm, pnlNoRsvp, pnlRsvp, pnlConfirm), pnlRsvpRules ); -- Granted, this would balloon the number of constructors throughout the framework just to save a bit of typing. Curious what others might think... Best regards, Zac Bedell - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RestartResponseAtInterceptPageException problem in 1.5
Greetings all, I've run into some trouble using RestartResponseAtInterceptPageException since moving from Wicket 1.4.13 to 1.5.3. The flow I'm implementing is a login via an OAuth service, so the user is redirected by way of RedirectPage to the OAuth provider and eventually ends up back at my site where continueToOriginalDestination() would send them back to the original page. The problem is that RestartResponseAtInterceptPageException is capturing the URL to the Link object which triggers the login rather than the Page containing the link, and the URL the user is eventually redirected to is incorrect. They end up with an AccessDeniedException rather than the originally requested page. The Wicket object hierarchy looks like: MyBasePage extends WebPage { public MyBasePage() { add(new LoginLink(…)); } } LoginLink { onClick() { throw new RestartResponseAtInterceptPageException(new RedirectPage(getOAuthUrl())); } } // User clicks LoginLink on SomePage which extends MyBasePage, redirect to OAuth provider works correctly, ends up back at: AuthCompletedPage extends WebPage { public AuthCompletedPage() { markSessionLoggedIn(…); continueToOriginalDestination(); } } All of the redirect plumbing seems to work fine, but stepping through shows that the URL captured in RestartResponseAtInterceptPageException.InterceptData.set() is the URL to the LoginLink component itself, not to the Page which hosts it. Specially, the URL captured looks like "/site/home?0-1.ILinkListener-pnlLogin-lnkTwitterLogin-lnk" whereas I would expect something more like "/site/home". In cases where the requested page already had page parameters, the ILinkListener bit as appended to existing parameters. When the smoke clears, the user ends up at AccessDeniedPage under the "ILinkListener" URL rather than seeing the original page redisplayed. Editing the URL to remove the query string at that point shows the home page as expected with the user properly authenticated. Drilling in with the debugger a bit, it looks like RestartResponseAtInterceptPageException.InterceptData.set() calls RequestCycle.get().getRequest().getOriginalUrl() which eventually delegates down to ServletWebRequest.getUrl(). I can understand why that URL would reflect the LoginLink object as it's in the Link's onClick handler, but my expectation (and the behavior in 1.4.13) would be that the Page hosting the Link would be saved for the eventual continueToOriginalDestination() rather than the link to the component executing the handler. I'm not sure if the AccessDenied is indicative of some other problem that might otherwise make this whole thing work properly, but it seems like a change in behavior at this point. So… Any advice would be appreciated. If there's some more correct way to handle authentication via third party OAuth redirect, I'm certainly open to changing my code. Thanks in advance, Zac Bedell - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org