Wicket
  1. Wicket
  2. WICKET-4500

InterceptData never cleared from session after continueToOriginalDestination is called

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.5, 1.5.6
    • Fix Version/s: 1.5.6, 6.0.0-beta2
    • Component/s: wicket
    • Labels:
    • Environment:
      Tomcat 6.0.29
      Linux or Windows (happens on both)

      Description

      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.

        Activity

        Hide
        Chris Colman added a comment -

        I forgot to add this comment:

        The problem occurs even with only a single user logon but it doesn't usually get noticed in that scenario but I can think of situations in which it could cause a problem. The InterceptData.clear never gets called in the simple process of the Admin user going to admin page getting redirected and then 'continued' after authentication.

        What is the mechanism by which the clear method gets called anyway? A static IRequestMapper is created but I can't see where it's ever referenced or used anywhere else in the code. Should it be mounted somewhere for it to work properly?

        Show
        Chris Colman added a comment - I forgot to add this comment: The problem occurs even with only a single user logon but it doesn't usually get noticed in that scenario but I can think of situations in which it could cause a problem. The InterceptData.clear never gets called in the simple process of the Admin user going to admin page getting redirected and then 'continued' after authentication. What is the mechanism by which the clear method gets called anyway? A static IRequestMapper is created but I can't see where it's ever referenced or used anywhere else in the code. Should it be mounted somewhere for it to work properly?
        Hide
        Chris Colman added a comment -

        I thought there might be a workaround for this problem while waiting for the fix but the InterceptData.clear method is not accessible as it's an inner class. I have no way of explicitly clearing the InterceptData so it's a bit of a show stopper for me at the moment.

        Show
        Chris Colman added a comment - I thought there might be a workaround for this problem while waiting for the fix but the InterceptData.clear method is not accessible as it's an inner class. I have no way of explicitly clearing the InterceptData so it's a bit of a show stopper for me at the moment.
        Hide
        Chris Colman added a comment -

        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.

        Show
        Chris Colman added a comment - 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.
        Hide
        Martin Grigorov added a comment -

        Hi,

        Please copy the comment above to a new ticket so we can track it separately.

        Don't you use the same approach to redirect for both types of users ?
        I mean if you use RestartResponseAtInterceptPageException in both cases then the second call should override the stored data from the first call and all should be fine.

        Show
        Martin Grigorov added a comment - Hi, Please copy the comment above to a new ticket so we can track it separately. Don't you use the same approach to redirect for both types of users ? I mean if you use RestartResponseAtInterceptPageException in both cases then the second call should override the stored data from the first call and all should be fine.
        Hide
        Chris Colman added a comment -

        I want slightly different behavior for both:

        The standard user's experience is very 'guided' and 'directed' by the system to avoid them ending up confused.

        When a standard user goes to home page they actually see the authenticate page. After authentication, if there was no previous intercept exception the authenticate page can determine the most appropriate place to send the standard user. If we had used RestartResponseAtInterceptPageException from the home page to the authentication page then the standard user will always end up at the home page after continueToOriginalDestination.

        The admin users are more tech savvy and so can request a particular url, get redirected to authenticate page if necessary, and then return to the page they desired.

        Show
        Chris Colman added a comment - I want slightly different behavior for both: The standard user's experience is very 'guided' and 'directed' by the system to avoid them ending up confused. When a standard user goes to home page they actually see the authenticate page. After authentication, if there was no previous intercept exception the authenticate page can determine the most appropriate place to send the standard user. If we had used RestartResponseAtInterceptPageException from the home page to the authentication page then the standard user will always end up at the home page after continueToOriginalDestination. The admin users are more tech savvy and so can request a particular url, get redirected to authenticate page if necessary, and then return to the page they desired.

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Chris Colman
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development