Hot Reload was introduced in .NET 6 and it is enabled by default in the latest versions of Visual Studio. The idea behind Hot Reload is that developers can modify code assets in their project and those changes will be immediately reflected in their run-time development environment. However there is some unexpected behavior you should be aware of.
The 3.1.1 release is primarily focused on stabilization, ensuring that all of the features introduced in 3.1 function as optimally as possible. This includes improvements to external login to include email verification logic for existing user accounts, improvements for retreiving user identifier claims, and the ability to customize your authentication cookie name for each site.
The key to understanding Antiforgery is that it is directly linked to the user's identity. This means that the antiforgery token and cookie that are generated by .NET Core are only valid for a specific user running in a specific context. So each time a user's identity changes ( ie.login/logout) new antiforgery tokens and cookies need to be generated for them to remain valid. This post explores how to resolve this challenge in a Blazor application.
The most common way of implementing Antiforgery is by using the [ValidateAntiForgeryToken] action filter on your actions or controllers (this is enabled by default on Razor Pages). However if your application supports multiple types of authorization it has some challenges. This dual authorization approach is common with APIs where you have a same-domain web application that relies on cookies but also supports external clients connecting via bearer tokens.
Thirty years ago this week Microsoft released Windows 3.1, the operating system which became the first version of Windows to be widely distributed with new PCs and cemented the dominance of Microsoft on the desktop in the decades to follow. In homage of this great achievement, we are extremely excited to announce the release of Oqtane 3.1.
One of the most common questions asked by new Blazor developers is how do you communicate between components? Essentially this questions boils down to state management... and the answer is that it depends on what you are trying to accomplish as there are many different solutions to consider, each catering to different UI scenarios.
The latest guidance from the IETF is that SPA applications which have a back-end should use the Backend for Frontend (BFF) architectural pattern. Oqtane uses the BFF architectural approach - both when running on Blazor WebAssembly and Blazor Server.
A common requirement in Oqtane is the need to identify changes for a specific site in your multi-tenant installation and deploy these changes into another environment. Oqtane 3.1 introduces a new Site Migration capability which allows you to codify the changes you wish to make to a specific site using an approach which is similar to EF Core data migrations and have the changes automatically applied on startup.