SpaProxy should not inject middleware with ASPNETCORE_HOSTINGSTARTUPASSEMBLIES

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

No response

Describe the solution you’d like

Injecting middleware with ASPNETCORE_HOSTINGSTARTUPASSEMBLIES prevents me from controlling the order middleware gets added to my pipeline. Frankly, I don’t even know why the feature exists, it seems to me like there would never be a good reason to use it. SpaProxy gets added to ASP.NET SPA projects through this variable right now and I hate it. Why is it so bad to add the middleware from Program.cs instead so the developer can choose the order in which it gets added? What if they want to run some middleware before the SpaProxy middleware?

Additional context

No response

[jez9999]

Could you give a concrete scenario where you would like to do this?

The SpaProxy is only meant to launch the proxy automatically after the .NET project starts. You can choose to remove it and launch the proxy manually or when your app starts.

I’d like to add some middleware where, on each call, it checks to see whether they’re authenticated and if not, it assigns a cookie on-the-fly (probably with SignInAsync) with a Guid as the user name identifier so that I can have anonymous users tracked to some extent across a session. Presumably if that has to run after the SpaProxy middleware it won’t get to have the opportunity to examine headers and set the cookie on each request.

[richstokoe]

That’s not the development experience that SPA frameworks support.

aspnetcore has supported this for several years, provided templates that lead us all to design solutions like this, demonstrated at conferences exactly this, and we’ve all built applications around this pattern. Now we need to perform non-trivial rearchitecture of our apps to support this new approach.

I’m fine with breaking changes, with enough notice, but the documentation is only now being written. Some of us are using LTS versions only because we’re in domains or projects that require it and 3.1 is EOL next month. We can’t move to 6 without redesigning our suite of services to match this approach.

Jez has followed the same pattern as we have:

I’d like to add some middleware where, on each call, it checks to see whether they’re authenticated and if not, it assigns a cookie on-the-fly

We host static Razor landing pages for speed of first load, and redirect to the SPA only once authentication (Cookie auth) has been completed.

This is a perfectly reasonable approach that maximises user experience.

We also like to ensure our development experience is close to production to spot issues early. That is also a reasonable expectation but one that is not possible with this new approach.

SPA frameworks will of course say to put the back end behind the SPA because they’re not building back end frameworks. Their incentives and responsibilities are not the same as the .NET team’s, nor should they be. ASP.NET allows hybrid applications with front and back ends in the same project, so we’ve all built them, and now this is unexpected TOIL with high risk (such as having to redesign, test, revalidate, and in some domains recertify with regulators, authentication mechanisms).

I still haven’t seen a valid reason why the aspnetcore team won’t support both ways even for one more LTS release. If this is how Microsoft will be treating its community going forward then we’ll just switch to something else.

We can’t know the routes the SPA targets because they are specific to each framework, but we know the ones that the Server targets, so we can actually very accurately configure the SPA proxy to automatically redirect the requests that would target the server.

You’re thinking about this too abstractly and making this choice for us - you might not know but we DO know the routes the SPA targets because we’re building the software. By putting the SPA proxy into the startup pipeline we can choose whether to redirect to auth, load the SPA, or load a Razor page. The solution provided now is to use Regex in JS files for routes, but just to work around the fact that the Dev inner loop is now different from the Production running behaviour.

Folks, this is not right.