Skip to content

Policy Duplicate Management #70

@mariajgrimaldi

Description

@mariajgrimaldi

Description

The Casbin enforcer operates only on what is currently loaded in memory. If the enforcer is not up to date with the datastore, it may not detect existing records and can create duplicate entries when policies or roles are added. This leads to inconsistencies in the database.

Problem

  • Duplicate policies: Because the enforcer does not refresh before write operations, it may re-insert the same policies multiple times.
  • No duplicate handling at adapter level: The Django adapter (add_policy) inserts into the database without checking for existing records.
  • In-memory mismatch: Clearing the enforcer and reloading policies avoids duplicates, but this is currently a manual process and not sustainable.

Observations

  1. With an empty database, the first run works fine (no duplicates).
  2. Running through python manage… reuses the SQLite3 binary, keeping state across runs.
  3. Each run loads default policies and additional assignments. These are inserted via add_policy, regardless of whether they already exist.
  4. In one test, clearing and reloading the enforcer on each operation prevented duplicates.

This suggests that duplicates occur because the enforcer is unaware of the current datastore state. Without a fresh load, it assumes no duplicates exist.

Requirements

  1. Implement a duplicate management strategy tied to the enforcer lifecycle:
    • Ensure the enforcer is always refreshed before write operations.
    • Clear and reload policies as part of the operation lifecycle.
  2. Explore adding duplicate detection in API functions themselves, making the public API self-contained and reliable even without lifecycle orchestration.
  3. Document the relationship between policy lifecycle management and duplicate prevention so that the behavior is predictable.

Acceptance Criteria

  • Duplicates are no longer created when policies or roles are added through the Public API or REST API.
  • Tests verify that consecutive runs, with policies pre-existing in the datastore, do not result in new duplicates.
  • Both strategies are considered:
    • Lifecycle management (load + clear before operations).
    • API-level duplicate checks.

Notes

  • This issue is closely related to Policy Lifecycle Load and Clear Management. A correct implementation of lifecycle management may already solve duplicates. However, API-level handling could provide an additional safeguard.
  • The adapter itself does not perform duplicate detection, so the responsibility lies in how we manage lifecycle and API behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions