.NET Core 1.1 WebAPI数据库角色权限授权方案技术咨询

Hey there, let's break down your .NET Core 1.1 WebAPI authorization setup—first, we'll look at the pain points in your current approach, then dive into actionable optimizations and troubleshooting tips.

• Hardcoded integer values: Converting enums like System.Administration to integers and shoving them into the attribute is a maintenance nightmare. If you ever update enum values or add new permissions, you’ll have to manually edit every attribute instance, which is error-prone and unreadable at a glance.
• Clunky attribute syntax: Piling multiple integer arrays into the MyAuthorization attribute makes the code messy. Adding or modifying permission groups means juggling brackets and values, which invites syntax errors.
• Coupled logic: If the authorization logic is baked directly into the MyAuthorization attribute, changing rules (like adding "OR" vs "AND" checks or role inheritance) will require modifying the attribute’s core implementation—violating the open/closed principle.
• Outdated framework version: .NET Core 1.1 is end-of-life, with no security patches or feature updates. Modern authorization features (like policy-based auth) are limited here, and staying on this version risks technical debt and security gaps.

1. Replace Hardcoded Ints with Strongly Typed Objects #

Wrap your permission triplets (system, process, action) in a dedicated class to boost readability and reduce errors:

public class PermissionRule
{
    public SystemEnum System { get; set; }
    public ProcessEnum Process { get; set; }
    public ActionEnum Action { get; set; }
}

Update your attribute to accept an array of these objects:

[MyAuthorization(new[] {
    new PermissionRule { System = SystemEnum.Administration, Process = ProcessEnum.AManagement, Action = ActionEnum.View },
    new PermissionRule { System = SystemEnum.Inventory, Process = ProcessEnum.BManagement, Action = ActionEnum.Disp },
    // Add more rules here
})]

Now you get IDE intellisense, clear readability, and no more guesswork about what those integers mean.

2. Migrate to Policy-Based Authorization (If You Can Upgrade) #

If you can upgrade to a supported LTS version like .NET Core 3.1 or 6.0, policy-based authorization is far more flexible than custom attributes:

• Define policies in your startup configuration:

services.AddAuthorization(options =>
{
    options.AddPolicy("AdminAManagementView", policy =>
        policy.RequireClaim("Permission", "Administration.AManagement.View"));
    options.AddPolicy("InventoryBManagementDisp", policy =>
        policy.RequireClaim("Permission", "Inventory.BManagement.Disp"));
});

• Apply policies directly to your endpoints:

[Authorize(Policy = "AdminAManagementView,InventoryBManagementDisp")]
[Route("something")]
[HttpGet]
public IActionResult GetSomething()
{
    // Your logic here
}

For complex rules, create custom IAuthorizationRequirement and AuthorizationHandler implementations to decouple permission logic from your controllers.

3. Externalize Permission Configurations #

Move API-to-permission mappings to a config file (like appsettings.json) so you can update permissions without changing code:

"ApiPermissions": {
    "/api/something": [
        { "System": "Administration", "Process": "AManagement", "Action": "View" },
        { "System": "Inventory", "Process": "BManagement", "Action": "Disp" }
    ]
}

Build a custom authorization filter that reads this config at startup and validates user permissions against the requested endpoint. This is ideal for environments where permissions change frequently.

4. Optimize Permission Validation Logic #

• Cache permissions: If you’re querying the database for user permissions on every request, add caching (MemoryCache or Redis) to reduce database load and improve performance.
• Decouple logic: Extract permission checking into a dedicated service (e.g., IPermissionValidator) instead of embedding it in the attribute. This makes the logic easier to test, modify, and reuse across your app.

1. Debug Authorization Failures #

• Enable debug-level logging in your app settings to track the authorization flow:

"Logging": {
    "LogLevel": {
        "Microsoft.AspNetCore.Authorization": "Debug"
    }
}

This will show you exactly what permissions the user has, what the attribute is expecting, and why the check failed.

• Add breakpoints or log statements inside your MyAuthorization attribute’s implementation to step through the validation logic.

2. Check Enum-to-Integer Conversion #

If permissions aren’t matching, verify that your enum-to-integer conversions are correct. For example, ensure no enum values are duplicated, and that you’re using the correct enum type when converting. Print the user’s permission integers and the attribute’s required integers during debugging to spot mismatches.

3. Validate Framework Compatibility #

If you’re seeing unexpected behavior after minor upgrades, double-check middleware order—UseAuthorization must come before UseMvc in your pipeline. Also, confirm that role/claim retrieval logic works with your .NET Core 1.1 setup (older versions have differences in how identity data is accessed).

4. Rule Out Caching Issues #

If updated database permissions aren’t taking effect, check if your permission cache is stale. Ensure cache expiration times are reasonable, or add a mechanism to clear the cache when permissions are modified.

内容的提问来源于stack exchange，提问作者krishnakumar