How to store the Permissions Definitions in SQL tables. #12530

3 Answer(s)

• 

  0

  oguzhanagir created one year ago

  Support Team

  Hi @conorcorr

  The permissions defined in the AppAuthorizationProvider within the application are reflected in the database table when the application is run. Did you check the database table (AbpPermissions) after adding the permissions?

  Ensure that the Authorization provider is added in the YourProjectNameApplicationModule as shown below.

  public override void PreInitialize()
  {
       //Adding authorization providers
       Configuration.Authorization.Providers.Add<AppAuthorizationProvider>();
       //...
  }
  

  Markdown is supported

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

  Save Cancel
• 

  0

  conorcorr created one year ago

  Hi @oguzhanagir,

  Thanks for the response. Here’s the behavior I'm observing:

      * When a new user is created, there are no entries in the AbpPermissions table.
      * When I edit a permission for that user, an entry is then created in the table.
  

  The behavior differs based on the user’s role:

  For the Admin role:

  * An entry is created in AbpPermissions only when a permission is explicitly removed (IsGranted = false).
  

  For the User role:

  * An entry is created in AbpPermissions when a permission is explicitly added (IsGranted = true).
  

  Is there a way to insert all permission entries for a user—at least with IsGranted = true—by default, regardless of the user’s role?

  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 @conorcorr

  The behavior you're seeing is not a bug it's a result of the ASP.NET Boilerplate - Zero's intentional design, which is built for efficiency.

  Why the AbpPermissions Table Works This Way

  The core of ASP.NET Boilerplate is to only save overrides from the default state to the database. This approach avoids unnecessarily bloating the database and improves performance.

  1. Permission Definitions: All permissions you define in your AppAuthorizationProvider are managed in memory by the IPermissionManager, not in the database. They represent the universe of all possible permissions in the system.

  2. Default Behavior:

     • Admin Role: The Admin role is typically configured to have all permissions granted by default. Therefore, when you revoke a permission from the Admin role (IsGranted = false), this is an exception. A row is inserted into the database to record this specific "exception." As long as the permission is granted, no record is needed because it follows the default behavior.
     • User Role (or other standard roles): Standard roles usually have no permissions granted by default. Therefore, when you grant a permission to such a role (IsGranted = true), this is also a deviation from the default state, and a record is added to the database to reflect this grant.

  3. The Purpose of the AbpPermissions Table: This table is not a list of all permissions. It is a table of overrides that supersede the in memory default settings for a specific user or role. When a permission check occurs (IsGrantedAsync), the system follows this structure:

     • First, it checks AbpPermissions for a user specific setting.
     • If none exists, it checks AbpPermissions for settings related to the user's roles.
     • If still no setting is found, it applies the default setting defined in memory (in the Permission definition).

  How to Store All Permissions in the Database?

  Your request to save all IsGranted = true permissions for a user to the database goes against the framework's natural flow. While you could do this manually, it is not recommended for the following reasons.

  • Database Bloat: Creating hundreds of permission rows for every single user would cause the AbpPermissions table to grow massive very quickly.
  • Performance Degradation: This could lead to more database queries during permission checks.
  • Maintenance: When you add a new permission to your application, you would need an additional mechanism to manually insert it for all existing users.

  Sharing Permission Definitions Across Microservices

  Since your ultimate goal is to share permission definitions across microservices, the correct approach is through code sharing, not by relying on the database for definitions.

  Create a Shared Core Library

  1. Create a New Project: Add a new library project to your solution, named something like .Shared

  2. Move the AuthorizationProvider: Move your AppAuthorizationProvider.cs file and its related constant classes (like AppPermissions) into this new shared project.

  3. Add a Reference: Add a reference to this new shared project from all of your microservices (including your main monolithic project, if you have one).

  4. Register in the Module: In each microservice's respective *ApplicationModule or *CoreModule file, ensure you register the shared AuthorizationProvider:

     public override void PreInitialize()
     {
         // Adding authorization providers from the shared library
         Configuration.Authorization.Providers.Add<AppAuthorizationProvider>(); 
     }
     

  With this method, all your microservices will load the exact same permission definitions into their memory on startup. Consequently, a check for permission x in one service will be understood and recognized by all other services.

  Markdown is supported

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

  Save Cancel