Making AbpPermission Entity Fully Auditable #12533

4 Answer(s)

• 

  0

  oguzhanagir created one year ago

  Support Team

  To make the AbpPermissions entity fully auditable and track changes in the EntityChanges table, you can follow the entity history feature's configuration steps. However, since AbpPermission is an internal entity of the ABP framework, direct auditing might not be straightforward or recommended. Here is a suggested path and an alternative, more robust solution.

  Enabling Entity History for AbpPermission

  You can try to enable entity history for the AbpPermission entity by following these steps, which are similar to how you would enable it for a custom entity:

  1. Enable Entity History: In your module's PreInitialize method (usually in YourProjectNameEntityFrameworkCoreModule.cs), ensure that entity history is enabled.

     public override void PreInitialize()
     {
         Configuration.EntityHistory.IsEnabled = true;
     }
     

  2. Register the Entity for Auditing: In the same file, you need to add AbpPermission to the list of tracked entities.

     public override void PreInitialize()
     {
         Configuration.EntityHistory.IsEnabled = true;
         Configuration.EntityHistory.Selectors.Add(
             new NamedTypeSelector(
                 "Abp.Authorization.Permissions.AbpPermission",
                 type => typeof(AbpPermission).IsAssignableFrom(type)
             )
         );
     }
     

  • Framework Entity: Directly auditing a framework entity like AbpPermission might have unintended side effects, as it's deeply integrated into the framework's authorization system. It's generally safer to avoid direct modifications or deep integrations with internal framework entities. Of course, here is the English version of that explanation.

  Recommended and Safer Approach: Auditing the RoleManager Method

  Instead of tracking the AbpPermission entity itself, a better and safer way is to audit the methods that perform these changes. You can do this by using the [Audited] attribute on the manager method that updates the permissions. This will give you a clear log of who changed which role's permissions and when.

  For example, you can override the SetGrantedPermissionsAsync method in your existing custom RoleManager class and add the [Audited] attribute:

  //...
  
  public class RoleManager : AbpRoleManager<Role, User>
  {
      // ...
  
      [Audited]
      public override Task SetGrantedPermissionsAsync(Role role, IEnumerable<Permission> permissions)
      {
          CheckPermissionsToUpdate(role, permissions);
  
          return base.SetGrantedPermissionsAsync(role, permissions);
      }
      
      // ...
  }
  

  By doing this, every time the SetGrantedPermissionsAsync method is called from anywhere in your application, an audit log entry will automatically be created in the AbpAuditLogs table. This log will capture the user who made the call, the parameters (including the role being changed and the list of granted permissions), and the time of the action. This gives you the desired traceability without interfering with the internal workings of the AbpPermission entity.

  This approach is generally the most robust and recommended way to handle auditing for such core functionalities centrally.

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel
• 

  0

  KieranIrl created one year ago

  Thank you, I like the idea of overriding the RoleManager class. Unfortunately our list of permissions often exceeds the max length (1024) of the Parameters column in the auditlogs table but we could of course capture this information in another table if needed.

  I understand we don't want to make the parameters length too long as it could impact performance.

  Making a new table with this roles auditing information may be the way to go.

  Thanks,

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel
• 

  0

  oguzhanagir created one year ago

  Support Team

  Hi @KieranIrl

  The AuditLogs table comes from ASP.NET Boilerplate. Here, the maximum length of the Parameters property is set to 4096. If your ABP packages are older versions, you can update them, or you can override the maximum length limitation for the AuditLog Parameters property within your ASP.NET Zero project.

  Related Code Line

  Thank you.

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel
• 

  0

  KieranIrl created one year ago

  Thank you, Even with 4k characters I suspect we still may run out. We'll certainly be able to work with overridding SetGrantedPermissionsAsync . Thanks

  Markdown is supported

  Copy & paste or drag & drop images (max 30 MB per image)

  Save Cancel