Spring Security
  1. Spring Security
  2. SEC-1411

Unexpected behaviour of getParameterValues in SavedRequestAwareWrapper

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.5
    • Fix Version/s: 3.0.2
    • Component/s: None
    • Labels:
      None

      Description

      Recently after session timeout we suddenly got duplicate values of certain parameters in our controllers.
      After some time we could figure out that the issue is related to the SavedRequest which is stored by ExceptionTranslationFilter into session. The SavedRequest contains the old values from the first request after session timeout which caused the authentication failure.

      The "real" issue comes from the method "getParameterValues(String name)" in "SavedRequestAwareWrapper".
      This method ALWAYS combines the parameter values of the SavedRequest with these from the current request resulting in duplicate values in the end if the values of a certain parameter are different now.
      Unfortunately the method "getParameterValues" has no javadoc at all describing this behaviour.
      In contrast "getParameterValue" of "SavedRequestAwareWrapper" behaves totally different (as the javadoc says)!

      For my opinion "getParameterValues" should be modified so it doesn't "merge" the parameters and only return the values of the "SavedRequest" when the current request does not have a certain parameter.
      Is the "merge" behaviour ever useful and/or needed?

      Please check if the method could be modified as suggested and however please update the javadoc accordingly.

      I've created a "workaround" by using "SecurityContextHolderAwareRequestWrapper" instead. This is perfectly save as we always redirect to the "defaultTargetUrl" after login.

        Activity

        Hide
        Luke Taylor added a comment -

        The merging behaviour is required for RequestDispatcher calls. If you search Jira you will find the details. Again, the request caching is more flexible in 3.0 and allows you to more easily substitute your own behaviour.

        Show
        Luke Taylor added a comment - The merging behaviour is required for RequestDispatcher calls. If you search Jira you will find the details. Again, the request caching is more flexible in 3.0 and allows you to more easily substitute your own behaviour.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Johannes Scharf
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: