Service to recalculate endpoint to execute with endpoint routing

[brockallen]

Is there a way to cause endpoint routing to re-calculate the endpoint that is to be executed? Perhaps as a service in DI?

My Scenario:
I have a middleware that is often registered after UseRouting. During request processing I have the need to re-write the request so it changes the request path (e.g. from /foo to /bar), but once the next middleware is executed which eventually ends up at UseEndpoints we get a 404 due to the now mismatched path.

I'd love a service in DI to help with this that I can trigger from my middleware.

[Tratcher]

https://github.com/dotnet/aspnetcore/blob/7bbaec1512682ab2a8f7d82440bc2bb428cc1857/src/Http/Routing/src/EndpointRoutingMiddleware.cs does use DI resolved services to match routes, but some of them are internal like MatcherFactory. It looks like it would be possible to wrap that logic in a public service.

[brockallen]

It looks like it would be possible to wrap that logic in a public service.

That'd be much appreciated.

[mkArtakMSFT]

@javiercn can you share some writeup about how this can be done, if it's easy? Thanks!

[davidfowl]

@mkArtakMSFT I think we'd need to expose public API here...

[javiercn]

My first suggestion would be to perform the url rewrite before app.UseRouting.

If for some reason that is not possible, I would try using a matcher policy to do it by:

• Creating a dynamic endpoint that matches the original route.
• Resolving to the destination endpoint.
• Updating information on the request if necessary.

If you can provide a more concrete example I can probably offer more targeted guidance.

[brockallen]

Well, it's part of IdentityServer's middleware. By default IdentityServer when it receives an authorization request and needs to render a response as HTML to post results back to a client it would normally render some hard coded HTML, but the customer might want their own (styling, branding, etc), so to achieve this I thought it'd be quite nice to re-execute in the pipeline to hit one of their endpoints (razor, MVC, whatever) to allow them to render the HTML.

[javiercn]

@brockallen I see.

I think there might be a better way to do that. The way I would go about it is as follows:

• Define an attribute for handling the specific UI endpoint you care about.
• For people who want to override the UI, require them to annotate their endpoint with your metadata.
• Mark your endpoint as dynamic (using DynamicMetadata).
• Write a MatcherPolicy that applies to your endpoint, finds the target endpoint on the endpoint data source, (accessible through routing options) and replaces it with the target endpoint.

If all you care is about being able to override the emitted response, that's the best way to go about it.

[javiercn]

Actually, it can be a bit simpler than what I'm suggesting. Assuming that you aren't using endpoint routing, in your middleware, when you hit the path, resolve the EndpointDataSource and search for an endpoint with your metadata on it (a controller with an attribute basically) and call context.SetEndpoint(endpoint) and that should do it.

Or check if the current selected endpoint has the metadata and noop in that case (let it override and handle the response) and produce a default otherwise.