Spring Security
  1. Spring Security
  2. SEC-1500

Target-URL changes while switching between secure and insecure channel, when it was encoded according to RFC 3986

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.0.3, 3.1.0.M1
    • Component/s: Web
    • Labels:
      None

      Description

      This issue is simmilar to the issue SEC-1255 "Target-URL after successfull login differes from original URL, when it was encoded according to RFC 3986"
      http://jira.springframework.org/browse/SEC-1255

      When switching the channel, AbstractRetryEntryPoint rebuilds the URL from its decoded parts.
      So, when switching on a URL, that containes a special character (like '?'), which is encoded according to RFC 3986, it changes the URL.
      For example, the URL "/foo%3Fbar.html", where "%3F" encodes the "?", becomes "/foo?bar.html", which is not encoded correctly, thus resulting in a 404-Error.

      Encoding the rebuild URL would not work, becaus all special characters (like contained slashes for example) would be encoded than, which is, as far as I know, not correct.

      I fixed the issue in my local git repository by calling the UrlUtils, which were fixed in issue SEC-1255, for building the redirect URL.
      I will apply my patch to this bug-report.

        Issue Links

          Activity

          Hide
          Kai Moritz added a comment -

          This is my patch for the AbstractRetryEntryPoint.
          Because UrlUtils appends a "://" to the scheme-parameter, I also had to patch RetryWithHttpEntryPoint and RetryWithHttpsEntryPoint.

          Show
          Kai Moritz added a comment - This is my patch for the AbstractRetryEntryPoint. Because UrlUtils appends a "://" to the scheme-parameter, I also had to patch RetryWithHttpEntryPoint and RetryWithHttpsEntryPoint.
          Hide
          Luke Taylor added a comment -

          Thanks for the patch. There are some minor problems with it (such as potential NPEs due to autoboxing) and it results in absolute URLs for all redirects (which should not be a problem but breaks tests). To keep things as simple as possible I've just modified the existing code to use the requestURI itself. The details may be revisited as part of SEC-1413, which would supersede these changes.

          Show
          Luke Taylor added a comment - Thanks for the patch. There are some minor problems with it (such as potential NPEs due to autoboxing) and it results in absolute URLs for all redirects (which should not be a problem but breaks tests). To keep things as simple as possible I've just modified the existing code to use the requestURI itself. The details may be revisited as part of SEC-1413 , which would supersede these changes.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Kai Moritz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: