Understanding separation of handlers
Something that still confuses me with the flexibility that the system provides is why (in your example) you would create two separate handlers for a BuildingEntryRequirement.
I understand that there are two different reasons why you can be authorised (sticker or badge) but why not just put both parts of the code into the same handler? Since the handler is explicitly tied to the requirement, I can't see how the handlers could ever be re-used i.e. every time you use a BuildingEntryRequirement, you would get both handlers executed.
The reason I ask is that it is still very easy to tie requirement to handler that the abstraction mechanism never seems to work. People want to access an admin page so they create an AdminRequirement and then an AdminHandler, in which cases it is a lot of indirection for no obvious gain!
Perhaps this could be explained in more detail in the section about running multiple handlers.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: b1141d92-adeb-6841-229f-914c808f9a2b
- Version Independent ID: 7089b376-949f-c1c6-c37a-5d8cc7ecf104
- Content: Policy-based authorization in ASP.NET Core
- Content Source: aspnetcore/security/authorization/policies.md
- Product: aspnet-core
- Technology: aspnetcore-security
- GitHub Login: @Rick-Anderson
- Microsoft Alias: riande