Constructors take vararg of Component? (Enhancement RFC)

[Zac Bedell]

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 FormRsvpPage(frmRsvp, cpm) {
  {
add(pnlNoRsvp, pnlRsvp, pnlConfirm);
  }
},
pnlRsvpRules
);

-- or --

FormRsvpPage frmRsvp = new FormRsvpPage(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 FormRsvpPage(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

[Zac Bedell]

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