September 27, 2021
Protecting Legacy .NET APIs with modern IdentityServer Tokens
The newest version of ASP.NET Core will be released in just a few days, the team announced this week. They’re targeting Wednesday, May 30, 2018, with an early-access release available already. I’m excited about many of the new features in this release, but I’ve highlighted a few favorites below.
If you’ve been developing in ASP.NET for very long at all, you’re probably already familiar with SignalR, but in case you’re not, it’s ASP.NET’s framework for pushing messages out over web sockets. It easily allows developers to create live-updating applications which receive data that is pushed from the server into the browser. Since its launch, ASP.NET Core has been missing this feature, but now it’s back, and better than ever. Its return sees many familiar classes and conventions, but the library has been heavily rewritten to improve things such as performance.
Microsoft recently announce SignalR as a service on Azure at their Build conference, which is built on ASP.NET Core’s implementation of SignalR. If you want to be able to scale your SignalR implementation up and down, it doesn’t get any easier than this!
In ASP.NET Core, Microsoft has merged what used to be MVC and Web API into a single, consistent framework. Anywhere that saw a difference between the two, the victory usually went to MVC. Because of that, there are a few things about creating API controllers in ASP.NET Core that feel a little wordy. Specifically, you have to mark up your code with a large number of attributes to get it to work the way you want.
Version 2.1 introductions the APIController Attribute. You can mark up your API controller class (or a base class) with this attribute just once, and get’s lot’s of API controller conventions applied to your class automatically. For example, now complex parameters types will be assumed to come from body without the FromBody attribute being specified, and more simple types will be assumed to come from the path without the FromUri. The action methods will also automatically check your ModelState to see if it’s valid, and returns a 400 message if it’s not.
A new generic return type has also been introduced, called ActionResult<T>. You no longer have to document your code with an attribute to tell things like OpenAPI (formerly know as Swagger) what type a method will return. The type you specify as the subtype of ActionResult<T> will be the documented return type, but you can still return other HTTP responses when you want to.
Finally, any JSON parsing errors will now give you error messages with more information about the mismatch to help you debug your code.
I’m really excited the there is now a project template for Angular applications that are Angular CLI-friendly, as well as other SPA templates hosted in ASP.NET Core. New project templates will also include General Data Protection Regulation (GDPR) implementations by default.
Have you ever noticed that adding ASP.NET Identity to a project adds A LOT of files, including a bunch of default razor views? By now allowing razor pages to be compiled into assemblies and packages, Microsoft has allowed us to bring complex pre-built views like these into our applications, just by making a reference or bringing in a Nuget package.
ASP.NET Core applications will now find views in referenced assemblies in addition to the standard view folders where that they’ve always looked. That means you can use all the views provided by a library, but override just one of them to be different in your application. OO comes to views!
Along with the changes listed above, ASP.NET Core Identity comes with a new scaffolder that will make it much easier to add ASP.NET Core Identity to an existing project. In the past, this was only really possible in a new project. If you wanted to add it to an existing one, it was a significant amount of manual work. No longer!
From now on, ASP.NET Core appliation templates will have HTTPS turned on by default. Microsoft has included a new HTTPS redirection middleware to allow you to intelligently redirect all traffic from an HTTP page to an HTTPS one.
Indeed, Kestrel will listen on both port 5000 (HTTP) and port 5001 (HTTPS) by default for debugging sessions, and you will have a certificate installed on your machine when you install the 2.1 SDK. If you want to work with dev certificates yourself, Microsoft has included a dev-certs tool in the CLI.
Apparently we developers kind of suck as using HTTPClient correctly. We create to many of them, for one thing, and they can eat up all the sockets on our machines, greatly impacting performance. HTTPClientFactory comes to the rescue by handling HTTPClient lifetimes for us.
Oh, and it’s also worth pointing out that the new HTTPClient has been now rewritten and is as mach as 10 times faster than in was before!
I haven’t really gotten into using Razor Pages instead of MVC very much, but the ASP.NET team has put a lot of effort into this feature recently. If you’re not familiar with it yet, I might describe it as a mashup of the best things about Web Forms and MVC, with less of the bad parts of each. ASP.NET Core 2.1 sees several nice improvements to this pattern.
The core of ASP.NET WebHooks receivers has now been ported into ASP.NET Core, allowing you to easily implement WebHooks. WebHookes are a simple way of sharing event notifications across different sites and services on the internet.
If you wanted to use different authentication schemes in different situations, that was difficult before in ASP.NET Core, but now it allows you to specify a “vitual” scheme as your authentication scheme. Within the virtual scheme, you can create your own logic based on anything you want to resolve to an actual authentication scheme.
Microsoft added a socket transport layer that you can use instead of the libuv layer that’s been there up until now. They warn that this isn’t quite ready for prime time yet, but that they think it has the potential to really improve the performance of ASP.NET Core applications even more.
This package differs from the existing Microsoft.AspNetCore.All meta-package in its reduced dependency on packages not owned or supported my Microsoft and includes just the minimum to make sure all the major framework features work. Think of this as “Microsoft.AspNetCore.Min”, where you can add any of the non-essentials pieces individually as needed.
If you’re interest in learning more about these new features, check out The ASP.NET teams blog post about it.