The Blazor series reprint has ended. In fact, the site owner finished reprinting on the 25th, synchronized it on the Dotnet9 website (https://dotnet9.com), and created an album "Learning Blazor Together Series", which everyone can browse at any time on the website.
Yesterday we talked about unit testing, but sometimes due to time constraints, comprehensive testing is not possible.
The most boring part of developing a system is probably fixing bugs, especially errors like trying to access a null object (`Object reference not set to an instance of an object.`), which is the most common problem most people encounter when they first step into programming. To break free from the tedious bug-fixing process, this article introduces `unit testing`.
It was mentioned earlier that `ASP.NET Core Identity` uses `Claim`-based authentication. In fact, `ASP.NET Core Identity` has different types of authorization methods, the simplest being `Login Authorization`, `Role Authorization`, and `Claim Authorization`. However, all of the above are implemented in one way: Policy-based Authorization.
As mentioned earlier, `ASP.NET Core Identity` is based on `Claim` authentication, and `Role` is a `Claim` with type `Role`
Yesterday, the `CRUD` functions for roles were completed. Next, we need to assign roles to users.
First, add a `ViewModel` to carry role data, because the upcoming permissions will be judged based on roles.
The day before yesterday, we added content in `Blog.razor` to display both authorized and unauthorized views. However, if the unauthorized content to be displayed is the same across the system, writing it in every component would be a waste of time. We can use `App.razor` to handle unified presentation.
Earlier, we mentioned `UserAuthentication()` and `UserAuthorization()`. The difference is that the former is used to verify who the user is, and the latter determines what the user can do.
Yesterday's authentication only targeted the Identity system and did not include our logs.