This behavior is by design.
I cannot say why AccessDeniedException is being thrown without
debugging it but I can suggest you to try:

LoginLink {
 onClick() {
  if (notLoggedIn) {
     throw new RestartResponseAtInterceptPageException(new

On Tue, Jan 3, 2012 at 2:04 AM, Zac Bedell <zacl...@thebedells.org> wrote:
> 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

Martin Grigorov
Training, Consulting, Development

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to