[
https://issues.apache.org/jira/browse/WICKET-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293401#comment-13293401
]
Chris Colman commented on WICKET-4500:
--------------------------------------
The above fix is great but we've run into another problem. If an admin user
attempts to go to a restricted page and gets redirected via a
RedirectToInterceptException but then decides not to log on but then goes to
the normal home page authentication and then successfully logs on as a standard
user that authentication will redirect to where the admin initially wanted to
go to - because they never authenticated as admin continueToOriginalDestination
was never called and so Wicket still thinks that when
continueToOriginalDestination is called after the standard user's
authentication that it needs to redirect to the original admin page... fun!
Would it be possible to introduce an explicit 'clearRedirect' method so that
when the home page does a RestartResponseException to redirect to the standard
user authentication page it can, at the same time, do a 'clearRedirect' so that
a subsequent call to continueToOriginalDestination does not attempt to go to
the admin page.
I can't remove the continueToOriginalDestination from the standard user
authentication page because it is still required to perform a continue when it
was reached by a RedirectToIntercepException from restricted pages other than
the home page.
> InterceptData never cleared from session after continueToOriginalDestination
> is called
> --------------------------------------------------------------------------------------
>
> Key: WICKET-4500
> URL: https://issues.apache.org/jira/browse/WICKET-4500
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.5, 1.5.6
> Environment: Tomcat 6.0.29
> Linux or Windows (happens on both)
> Reporter: Chris Colman
> Assignee: Martin Grigorov
> Labels: wicket
> Fix For: 1.5.6, 6.0.0-beta2
>
> Attachments: continueDestinationNotCleared.zip
>
>
> We have a scenario where single person can log in under different accounts on
> the same website. Different user types will typically go to different page
> types.
> A single person using different accounts is not normally required but we are
> demonstrating to corporate clients how the system will be used by different
> user types. In the demonstration we need to log in as an 'admin' user to demo
> the admin aspects and then we need to log in as a 'standard' user to
> demonstrate the aspects that will apply to a standard user.
> The admin page uses RedirectToInterceptException to authentication page if no
> one is logged in.
>
> The standard page uses the home page to authenticate and throws new
> RestartResponseException(new AuthenticatePage(parameters)) if no one is
> authenticated (i.e. no intercept)
> After authentication we either continue or go to the 'default' page for a
> standard user.
>
> Code looks like this:
>
> If ( authenicationSucceeded )
> {
> if ( !continueToOriginalDestination() )
> {
> // Was not redirected to this
> authentication page so go to default destination for the home page
> // Find default page for
> standard users and go to that page
> }
> }
>
> What we find is that after an admin log on (with intercept/continue sequence)
> a subsequent standard user log on will not execute the above body because
> continueToOriginalDestination returns 'true' even though this page was not an
> intercept page.
> It looks like after an intercept/continue has occurred it does not clear the
> 'original destination' attribute and so a subsequent call to
> continueToOriginalDestination will return true when it should really return
> false.
> The quickstarts demonstrates the problem:
> Point browser to localhost/app/landing
> Click 'logon'
> Click 'Click to continue' - each time you click continueToOriginalDestination
> is called which successfully does a continue as evidenced by the page counter
> incrementing.
> If running in a debugger set a break point on
> RestartResponseAtInterceptPageException.InterceptData.clear().
> Restart the app and then click on 'logon' and you will never see the clear
> method executed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
