2.2 Roadmap discussion

[glennc]

Discussion for the 2.2 Roadmap announcement: aspnet/Announcements#307

[iAmBipinPaul]

What about EF Core 2.2 Roadmap?

[benaadams]

What about EF Core 2.2 Roadmap?

aspnet/Announcements#308

[RehanSaeed]

Roadmap looks good, particularly health checks and HTTP 2.0. However, in the kindest possible way, I disagree with the need to build a simple first party Microsoft authorization server. IdentityServer4 fills this gap nicely and the time spent re-implementing a simpler version of it could be better spent elsewhere. I understand the goal is to provide a simple solution but auth is hard and IdentityServer provides an API that is about as simple as it gets. If there are ideas for a simpler abstraction, it could be built on top of IdentityServer so people can use the simple abstraction but have the power if they need it.

Update

In the ASP.NET Community standup, it was mentioned that the ASP.NET Core team is talking to the Identity Server team about the options, including building something on top of Identity Server. I think that's what we all want, well done!

[tpeczek]

What are the current plans around ASP.NET Core WebHooks?

[arishlabroo]

Regarding the dispatcher, will this be possible in the middleware then? 😱

public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)

^{[FromQuery]? 🤔}

[imranbaloch]

Simple Auth Server but also remember what happened with Katana simple Auth Server

[poke]

I want to echo @RehanSaeed’s concerns and would like to ask for some clarifications on what exact use cases this new server is supposed to fill. If this is primarly so web APIs have a way to get their bearer token that is valid within the existing authentication of the app, then that would be fine. But everything on top of that is probably better left to the existing solutions which already offer many options of different complexity and flexibility with products like IdentityServer, OpenIddict, and AspNet.Security.OpenIdConnect.Server.

[SIkebe]

What about IIS in-process hosting?

[stefan-schweiger]

Could you elaborate more on the TypeScript part of "API client generation (C# & TypeScript)"?

This would be really something I would look forward to. Currently I'm using NSwag for auto-generating my Angular Client API Services. But there are just so many different combinations possible for client configurations that I think this could be problematic to please everyone.

Just off the top of my head, some thing that should be considered (and if possible should be configurable):

• Just a TypeScript client with fetch or an Angular Service with HttpClient?
• If it's Angular, which versions do you support (also important for RxJS)?
• null/undefined handling
• enum handling
• JS date or momentjs for date types?
• Exception handling, Validation error handling
• How to extend the generated code in the client?
• Possibility to influence name generation (e.g. dropping the DTO part from xxxDTO for the generated client classes or already at the OpenAPI definition)

[RehanSaeed]

If it was possible to vote for features, these improvements/fixes to existing middlware would be on my wishlist:

• Lets Encrypt support Let's Encrypt and SCIM #1190.
• The Response Cache middleware is basically not usable as it is today. Adding a Redis response cache store and extensibility for user operations of cached responses should solve Caching response with Authorization header #2606.
• Support serving of pre-GZIP and pre-BR encoded files.
• Add a Brotli Compression Provider as well as fixing several issues with the response compression middleware.

[manigandham]

I also vote to skip the Authorization Server product. Security is complicated and there has been a big push to move to cloud services to remove maintenance, and anyone who wants more control can already use IdentityServer4 which is well-built, tested, documented, and supported. A simple setup takes 5 minutes and they have plenty of starter samples, videos, and tutorials.

I fail to see how you can make security work as "zero config" any more than they can. It seems like this will just add more confusion (in naming and usage), while becoming yet another thing to support and maintain for years, taking effort away from other features continuously. Please rethink this.