Permission-Check API on Properties with User Context

[jovermier]

Summary

Introduce a top-level query in Hasura to allow developers to programmatically check permissions for roles across multiple properties (fields, nested objects, and sub-properties). This query would evaluate whether a role has insert, update, select, or delete permissions dynamically while respecting row-level conditions and context, including custom checks logic.

Problem Statement

Hasura’s role-based permission system is powerful, particularly with features like row-level permissions and custom checks that can incorporate complex logic. However, this complexity makes it difficult to keep the UI or application logic in sync with Hasura permissions, especially for row-level checks.

• Custom Check Complexity:
  Hasura allows defining custom checks on row-level permissions using expressions based on session variables, relationships, or computed columns. While this feature is flexible, it introduces a challenge:
  • The custom check logic must be manually replicated in the frontend/UI or other services to determine whether a user has access to a specific row or property.
  • For dynamic UIs, this replication is error-prone, time-consuming, and may fall out of sync with the backend logic.
• Dynamic Data Representation:
  For nested objects or complex data relationships, evaluating permissions for deeply nested fields becomes even harder, as permissions may vary across fields or rows.

The lack of a unified way to programmatically validate permissions leads to permission drift and inefficient workflows where developers must attempt operations to determine access.

Proposed Solution

Add a top-level query that accepts an array of properties (with optional nested structures) and returns detailed permission information (insert, update, select, delete) for each property.

API Design

GraphQL Query Example

query CheckPermissions(
  $role: String!,
  $user_id: uuid!,
  $properties: [PropertyPermissionInput!]!,
  $context: jsonb # Optional: Custom context variables (e.g., session variables or headers)
) {
  check_permissions(role: $role, user_id: $user_id, properties: $properties, context: $context) {
    property_path # Full path of the property (e.g., "business.name" or "business.employees[].name")
    permissions {
      insert # Boolean
      update # Boolean
      select # Boolean
      delete # Boolean
    }
    reason # Optional: Explanation for denial (e.g., "Role has no insert access on 'name'")
  }
}

Input Parameters

• role (required): The role for which to check permissions (e.g., user, admin).
• properties (required): An array of properties or nested objects to check permissions for.
• user_id (optional): The user's ID to check permissions for. Automatically taken from the session of not supplied. This aligns with Hasura's ability to apply permissions based on session variables such as x-hasura-user-id.

Property Permission Input Schema:

input PropertyPermissionInput {
  property: String! # The name of the property (e.g., "name", "employees")
  children: [PropertyPermissionInput] # Optional nested properties
}

Example Input:

{
  "role": "user",
  "properties": [
    { "property": "name" },
    { "property": "address" },
    { 
      "property": "employees", 
      "children": [
        { "property": "name" },
        { "property": "role" }
      ]
    }
  ]
}

Output

Each property in the input array would have a corresponding response object with detailed permissions.

Example Output:

{
  "data": {
    "check_permissions": [
      {
        "property_path": "name",
        "permissions": {
          "insert": true,
          "update": true,
          "select": true,
          "delete": false
        }
      },
      {
        "property_path": "address",
        "permissions": {
          "insert": false,
          "update": false,
          "select": true,
          "delete": false
        }
      },
      {
        "property_path": "employees.name",
        "permissions": {
          "insert": true,
          "update": false,
          "select": true,
          "delete": false
        }
      },
      {
        "property_path": "employees.role",
        "permissions": {
          "insert": false,
          "update": true,
          "select": true,
          "delete": false
        }
      }
    ]
  }
}

Benefits

1. Dynamic UI Adjustments:
   • Easily hide or disable UI components based on whether the user has access to specific properties.
   • Example: Disable "Edit" or "Delete" buttons for fields or rows without update or delete permissions.
2. Nested Permission Checks:
   • Check permissions for deeply nested properties without manually querying each level.
3. Simplified Development:
   • Eliminate the need to replicate Hasura permissions in the UI or services.
4. Consistent Permission Management:
   • Keep permissions centralized in Hasura, reducing the risk of permission drift.
5. Scalable Input Structure:
   • Flexible input format supports both flat properties and complex nested structures.

Use Cases

1. Dynamic Field Visibility:
   • Before rendering a form or data grid, query permissions to determine if fields should be visible, editable, or restricted.
2. Preemptive Validation:
   • Validate permissions before attempting operations like inserting or updating nested data.
3. Debugging and Auditing:
   • Provide detailed feedback to developers and admins on why certain actions are disallowed.

Conclusion

A check_permissions query with user context would greatly enhance Hasura's usability by centralizing permission checks and reducing duplication of logic in UI and services. This feature would provide developers with a powerful tool to build dynamic, user-specific experiences while ensuring security and consistency with Hasura's permission system.

[seanparkross]

Hi @jovermier
Was this suggestion for Hasura v2 or DDN?
If v2, there won't be further development like this on that product.
I have reported the feature suggestion though to the DDN team.
Thanks! 🙏 🙏

[jovermier]

I currently use v2, really like v2, and didn't have plans to move to DDN. Both products I am sure could benefit from this feature.