[release/2.1] Fix windows auth when we receive a 401 after auth completes #32243
Conversation
PR #31589 introduced a regression in the case where we receive another 401 after Windows auth completes (this is caused by the user being successfully authenticated, but not authorized to access the specified resource). We were incorrectly draining the response in this case. As a result, the user would receive a disposed response and eventually throw an ObjectDisposedException. The fix is to adjust the logic here where we only drain if we know we are going to send another request for the rest of the Windows auth (Negotiate/NTLM) challenge-response handshake. Add new unit test for Windows auth scenario.
davidsh
added
tenet-compatibility
Shiproom templateDescriptionReceiving another 401 after Windows auth completes (this is caused by the user being successfully authenticated, but not authorized to access the specified resource) is resulting in an incorrect ObjectDisposedException being thrown due to incorrectly draining the response stream. This is causing HTTP requests to fail. The fix is to adjust the logic so that we only drain the response stream if we know we are going to send another request for the rest of the Windows auth (Negotiate/NTLM) challenge-response handshake. Customer ImpactHTTP requests that successfully authenticate but are unauthorized for the particular resource will throw ObjectDisposedException instead of returning a normal HttpResponseMessage with 401 status code. This already has broken ASP.NET scenarios. Regression?Regression from 2.1.4 Packaging reviewed?N/A. System.Net.Http.dll is not built as a separate package. RiskLow. Added new unit tests to verify scenario with Windows authentication. Link to issue#32143 |
HttpListener isn't supported on NanoServer sku since http.sys is not present.
|
@dotnet-bot test Outerloop Windows x64 Debug Build |
|
LGTM |
|
Failures in CI unrelated to PR. |
jamshedd
added
Servicing-approved
|
Approved for 2.1.5. |
danmoseley
added
Servicing-approved
4 participants
PR #31589 (2.1.5) introduced a regression in the case where we receive another 401 after Windows auth completes
(this is caused by the user being successfully authenticated, but not authorized to access the specified
resource). We were incorrectly draining the response in this case. As a result, the user would receive
a disposed response and eventually throw an ObjectDisposedException.
The fix is to adjust the logic here where we only drain if we know we are going to send another request
for the rest of the Windows auth (Negotiate/NTLM) challenge-response handshake.
Add new unit test for Windows auth scenario.