Arnljot Arntsen (Migrated from SEC-1271) said:
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.
Arnljot Arntsen said:
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.
Luke Taylor said:
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.
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.
OK, thanks for confirming.