Re-run routing for implicit middlewares that require endpoints #49732
Conversation
dotnet-issue-labeler
bot
added
the
area-auth
captainsafia
added
area-minimal
captainsafia
force-pushed
the
safia/wab-implicit-middleware-fix
branch
from
ba8b19f to
8a1c68c
Compare
src/Security/Authorization/Policy/src/AuthorizationAppBuilderExtensions.cs
Show resolved
Hide resolved
src/Security/Authorization/Policy/src/AuthorizationAppBuilderExtensions.cs
Outdated
Show resolved
Hide resolved
src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/WebApplicationTests.cs
Outdated
Show resolved
Hide resolved
src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/WebApplicationTests.cs
Outdated
Show resolved
Hide resolved
| @@ -2697,7 +2699,7 @@ public void DebugView_UseMiddleware_HasMiddleware() | |||
| // 3. Generated delegate name from app.Use(...) | |||
| Assert.Collection(debugView.Middleware, | |||
| m => Assert.Equal(typeof(MiddlewareWithInterface).FullName, m), | |||
| m => Assert.Equal("Microsoft.AspNetCore.Authentication.AuthenticationMiddleware", m), | |||
| m => Assert.StartsWith("Microsoft.AspNetCore.Builder.AuthAppBuilderExtensions", m), | |||
There was a problem hiding this comment.
Do we care about these values?
There was a problem hiding this comment.
Not sure exactly what you mean. I updated the check because I wanted to avoid having the generated name of the delegate-based middleware here. I think it stays mostly consistent but I wanted to avoid typing out the whole thing.
Also, it's a helpful indicator of what codepath you went through (re-routed middleware or plain middleware).
There was a problem hiding this comment.
I meant in the case of consumable data, can customers only see this in the debugger? Or should we treat it more like public API and try to have nicer names show up?
I think so. I'll have to double check that it does repro in .NET 7 (probably) and author a separate bug fix for it. We can't backport directly since we made substantial changes to the WebApplicationBuilder in .NET 8. |
ghost
added this to the 
Closes #49654.
Auth-related middlewares set state on the HttpContext to indicate that they have run when an endpoint is available so that the endpoints middleware can warn if endpoints that should've been evaluated by the middleware have not been.
The WebApplicationBuilder registers a set of auth-related middlewares implicitly when their associated services are registered. When the user calls
UseRoutingexplicitly in their application code, the middlewares are registered after and are not able to examine the endpoint set by the routing middleware.A combination of these factors means that users receive erroneous warnings that auth-related middlewares have not run on endpoints when they have (as in the issue above).
To resolve this, we force routing to run in the middlewares that need to set state in reaction to it.