Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: 3.0.0.RC2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Tomcat6.0
      Spring Security 2.0.0
      Spring2.5

      Description

      According to SEC-308 and SEC-315, this issue is supposedly fixed. But code is not in the distribution.

      See attatched ntlm sample of how it failes in org.springframework.security.ui.ntlm.NtlmProcessingFilter.doFilterHttp line 328:
      final String authMessage = request.getHeader("Authorization");

      This returns null as the header is "authorization" as it's the normalized name Tomcat stores headers.

        Activity

        Hide
        Arnljot Arntsen added a comment -

        As far as I can read from the current release candidate 3.0 and the stable release 2.0.8, the issue is present in both code trees.

        Show
        Arnljot Arntsen added a comment - As far as I can read from the current release candidate 3.0 and the stable release 2.0.8, the issue is present in both code trees.
        Hide
        Luke Taylor added a comment -

        The implementation of SavedRequest uses a case-insensitive comparator to store the headers and we have unit tests which show that header matching is case-insensitive.

        If you are sure that headernames are still being compared in a case-insensitive manner, please provide clear evidence that this is the case.

        NTLM is no longer supported in the codebase (it isn't in 3.0 RC1) and it seems more likely that this is a artifact of the NTLM implementation.

        Show
        Luke Taylor added a comment - The implementation of SavedRequest uses a case-insensitive comparator to store the headers and we have unit tests which show that header matching is case-insensitive. If you are sure that headernames are still being compared in a case-insensitive manner, please provide clear evidence that this is the case. NTLM is no longer supported in the codebase (it isn't in 3.0 RC1) and it seems more likely that this is a artifact of the NTLM implementation.
        Hide
        Arnljot Arntsen added a comment -

        Yes, it seems like a side effect of the NTLM filter. It tries to access the request, which is a SavedRequest inside a SavedRequestAwareWrapper, the new headers which has been set by the client(browser) is not available in the second request.

        So this issue may be closed.

        Show
        Arnljot Arntsen added a comment - Yes, it seems like a side effect of the NTLM filter. It tries to access the request, which is a SavedRequest inside a SavedRequestAwareWrapper, the new headers which has been set by the client(browser) is not available in the second request. So this issue may be closed.
        Hide
        Luke Taylor added a comment -

        OK, thanks for confirming.

        Show
        Luke Taylor added a comment - OK, thanks for confirming.

          People

          • Assignee:
            Unassigned
            Reporter:
            Arnljot Arntsen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: