Hi,
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
RedirectPage(getOAuthUrl()));
}
}
On Tue, Jan 3, 2012 at 2:04 AM, Zac Bedell <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
