aspnetcore: SpaProxy should not inject middleware with ASPNETCORE_HOSTINGSTARTUPASSEMBLIES

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.

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.

I just think that’s exaggerated. I’m developing a Vue application using the old ASP.NET dev proxy and hot reloads work fine, as do WebSockets. Basically you could keep supporting that way of doing things if you wanted, whether SPA frameworks “bless” it or not.

@javiercn If the asp.net core process is going to be the front-facing web server on production, doesn’t it make more sense for it to be in development too? If an asp.net route will take precedence over a JS one, it ought to do so just the same on dev and prod. Both options should be supported.

@richstokoe Yes, I think the right approach would be for Microsoft to actively support both approaches going forward, even if the new approach is default, the old one should remain an option for those of us who prefer it.