Uh oh!
There was an error while loading. Please reload this page.
Make handling of DefaultCredentials in NegotiateAuthentication/SocketsHttpHandler more consistent - #91160
Conversation
ghost
commented
Aug 26, 2023
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones Issue DetailsSee PR #91138 for alternative approach. Report |
| Author: | filipnavara |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
There was a problem hiding this comment.
I think this should be an && between username and password.
There was a problem hiding this comment.
It was always || in all versions on .NET. It's not like empty user name with non-empty password, or vice versa, makes any sense.
There was a problem hiding this comment.
it's not? I've seen services that only require password with empty username.
There was a problem hiding this comment.
I don't think that's valid in NTLM or Kerberos. It's valid in Basic authentication.
4850719 to
fd2af56Compare…ionPal implementation for NTLM w/ default credentials. This was handled inconsistently between the managed NTLM implementation and the GSSAPI one. Add test for the behavior. Add test to ensure SocketsHttpHandler using CredentialCache.DefaultCredentials with NTLM doesn't throw PNSE exception and returns the Unauthorized HTTP response instead.
fd2af56 to
f2d7525Compare
See PR #91138 for alternative approach.Report
UnknownCredentialsstatus on Unix/Managed NegotiateAuthenticationPal implementation for NTLM w/ default credentialsthrowingcommunicating back withPlatformNotSupportedExceptionwith a useful message that explains which parameters are unsupportedNegotiateAuthenticationStatusCode.UnknownCredentials.SocketsHttpHandler
CredentialCache.DefaultCredentialswith NTLM doesn't throw PNSE exception and returns theUnauthorizedHTTP response instead.Fixes#91131