I have a few comments about this approach:

1. Can we create a package called engine to move these kinds of definitions there? We could use it for all definitions related to our authorization engine.
2. Can we implement a class instead, called Enforcer (or another most distinguished name) that behaves like this enforcer but sets up the watcher as part of its initialization (ducktyping)? We could also implement more customizations if needed.
3. Do we have to initialize the watcher manually here everytime we get an enforcer? Can't we use CASBIN_WATCHER setting instead or is it configured per enforcer-instance?
4. Do we need an enforcer per django process?

1. Yes, I think that’s a good idea. Centralizing all those definitions we’ll need later seems like the most appropriate approach.
2. Yes, I agree. We should have a class that wraps the original Enforcer. That way we could initialize the Watcher, Adapter, or anything else, or add any custom methods we need, such as load_filtered_policy.
3. I wasn’t aware of the CASBIN_WATCHER setting. It could be useful to avoid the issue you mentioned. I’ll be running some tests with that configuration.
4. Casbin doesn’t share state across processes, so a watcher would be needed to synchronize changes. Is that what you’re referring to?

I wasn’t aware of the CASBIN_WATCHER setting. It could be useful to avoid the issue you mentioned. I’ll be running some tests with that configuration

See #37 (comment)

This request middleware loads the entire policy into memory using enforcer.load_policy: https://github.com/pycasbin/django-authorization/blob/83a70ddcc2cd53c152b6de5f31af974c658918f9/dauthz/middlewares/request_middleware.py#L7-L15 which could severely impact performance in real production settings. I don't think using this middleware as is is viable for our use case.

This also takes me to this question here: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5210112002/WIP+Open+edX+AuthZ+Framework+Long-Term+Vision?focusedCommentId=5220433941. Django ORM adapter which is used by this library doesn't support loading filtered policies, which again is not a viable option for us loading an entire database into memory. What I think we could do is implementing our own extended adapter which filters policies, using as guide what's already implemented in the adapter itself and also in other python adapters which do support filtering policies like https://github.com/officialpycasbin/sqlalchemy-adapter

We could do something like (pseudocode, haven't tested it):

from casbin_adapter.adapter import Adapter
from casbin_adapter.models import CasbinRule

class ExtendedAdapter(Adapter):
    def __init__(self):
        super().__init__()

    def load_filtered_policy(self, filter):
        """Load only policy rules that match the filter.

        This filter should come from a more human-readable query format, e.g.:
        {
            "ptype": "p",
            "rule": ["alice", "data1", "read"]
        }
        """
        query_params = {"ptype": filter.get("ptype")}
        for i, v in enumerate(filter.get("rule", [])):
            query_params["v{}".format(i)] = v
        return CasbinRule.objects.using(self.db_alias).filter(**query_params).all()

I tested this in the django shell, it seems to work:

In [3]: enforcer.adapter
Out[3]: <openedx_authz.engine.adapter.ExtendedAdapter at 0x71ca1e7e18d0>

In [4]: enforcer.adapter.load_filtered_policy({"ptype": "p", "rule": ['anonymous', '/login', '*']}) 
Out[4]: <QuerySet [<CasbinRule 2: "p, anonymous, /login, *">]>

The filter will probably have to be more complex and the query used should also consider other use cases like loading for a single org etc which I haven't tested. At least I think this could work.

There is still a concern about the performance implications of these queries, though.

2748819

Thanks for your comment!

Yes, based on what you mentioned, we shouldn’t use the default Middleware. I also tested your implementation, but I wonder if we should do something additional. You’re calling enforcer.adapter.load_filtered_policy, but we should be able to use the enforcer directly like enforcer.load_filtered_policy.

I’m also noticing that if we don’t use the middleware, the django-authorization library isn’t necessary. I’m running some tests using only the Django ORM Adapter.

Based on your code and the SQLAlchemy adapter, I created this ExtendedAdapter (It may need some optimization, but the adapter seems to work correctly with the new method.)

# openedx_authz.engine.adapter

from casbin import persist
from casbin.persist import FilteredAdapter
from casbin_adapter.adapter import Adapter
from casbin_adapter.models import CasbinRule


class ExtendedAdapter(Adapter, FilteredAdapter):
    """
    Extended adapter for the casbin model.
    """

    _filtered = False

    def load_filtered_policy(self, model, filter) -> None:  # pylint: disable=redefined-builtin
        """loads all policy rules from the storage."""
        queryset = CasbinRule.objects.using(self.db_alias).all()
        filtered_queryset = self.filter_query(queryset, filter)
        for line in filtered_queryset:
            persist.load_policy_line(str(line), model)
        self._filtered = True

    def filter_query(self, queryset, filter):  # pylint: disable=redefined-builtin
        """filters the queryset based on the attributes of the filter."""
        for attr in ("ptype", "v0", "v1", "v2", "v3", "v4", "v5"):
            filter_values = getattr(filter, attr)
            if len(filter_values) > 0:
                filter_kwargs = {f"{attr}__in": filter_values}
                queryset = queryset.filter(**filter_kwargs)

        return queryset.order_by("id")

# openedx_authz.engine.filter

class Filter:
    """
    Filter class for the casbin model.
    """

    ptype = []
    v0 = []
    v1 = []
    v2 = []
    v3 = []
    v4 = []
    v5 = []

I did some tests, and it seems to work:

In [1]: from openedx_authz.engine.filter import Filter

In [2]: from casbin_adapter.enforcer import enforcer as e

In [3]: f = Filter()

In [4]: f.v0 = ["alice"]

In [5]: e.load_filtered_policy(f)
2025-09-10 22:52:36,830 INFO 147 [casbin.policy] [user None] [ip None] policy.py:73 - Policy:
2025-09-10 22:52:36,830 INFO 147 [casbin.policy] [user None] [ip None] policy.py:79 - p : sub, obj, act : [['alice', 'data1', 'read']]
2025-09-10 22:52:36,831 INFO 147 [casbin.policy] [user None] [ip None] policy.py:79 - g : _, _ : [['alice', 'data2_admin']]
2025-09-10 22:52:36,831 INFO 147 [casbin.policy] [user None] [ip None] assertion.py:48 - Role links for: g
2025-09-10 22:52:36,831 INFO 147 [casbin.role] [user None] [ip None] role_manager.py:218 - alice < data2_admin

In [6]: e.get_policy()
Out[6]: [['alice', 'data1', 'read']]

In [7]: f.v0 = ["bob"]

In [8]: e.load_filtered_policy(f)
2025-09-10 22:52:48,271 INFO 147 [casbin.policy] [user None] [ip None] policy.py:73 - Policy:
2025-09-10 22:52:48,272 INFO 147 [casbin.policy] [user None] [ip None] policy.py:79 - p : sub, obj, act : [['bob', 'data2', 'write']]
2025-09-10 22:52:48,272 INFO 147 [casbin.policy] [user None] [ip None] policy.py:79 - g : _, _ : []
2025-09-10 22:52:48,272 INFO 147 [casbin.policy] [user None] [ip None] assertion.py:48 - Role links for: g
2025-09-10 22:52:48,272 INFO 147 [casbin.role] [user None] [ip None] role_manager.py:218 - 

In [9]: e.get_policy()
Out[9]: [['bob', 'data2', 'write']]

This is the new Casbin config using only the Django ORM Adapter:

casbin_adapter_app = "casbin_adapter.apps.CasbinAdapterConfig"
    if casbin_adapter_app not in settings.INSTALLED_APPS:
        settings.INSTALLED_APPS.append(casbin_adapter_app)

# Add Casbin configuration
settings.CASBIN_MODEL = os.path.join(ROOT_DIRECTORY, "model.conf")
watcher_options = WatcherOptions()
watcher_options.host = "redis"
watcher_options.port = 6379
watcher_options.optional_update_callback = callback_function
watcher = new_watcher(watcher_options)
settings.CASBIN_WATCHER = watcher
settings.CASBIN_ADAPTER = "openedx_authz.engine.adapter.ExtendedAdapter"

Great! Where can we get the redis configurations though? I see it's in the CACHE dictionary or maybe this could be part of a casbin.py on each installation - which is not tied directly to lms/cms

This should be a file part of a tutor plugin instead so it can be loaded and accessed as a volume and properly maintained by operators.

I agree!