Stuck on Casbin's model.conf? 5 mistakes beginners hit most

Struggling with Casbin's model.conf? Here are the five mistakes that beginners commonly make when working with this permission framework. Casbin works across multiple programming languages, including Go, Java, Python, and Node.js. Its architecture is defined by the model.conf file, which outlines the rules, while the policy stores the data.

1. The matcher field names may not match the request or policy columns. The columns declared in [request_definition] and [policy_definition] are the only ones the matcher can use, and their order is crucial. For instance, if your request is "alice reads data1" but you accidentally swap the action and object, the matcher will return false, and no error will be raised. This makes it challenging to debug the issue.

2. Understanding how g() works is essential. The function g(r.sub, p.sub) is not magical; it checks if the subject (r.sub) is equal to the policy subject (p.sub), either directly or through role inheritance. A common mistake is assuming that g() alone is sufficient. In reality, role relationships must also be defined in the policy using g rows. If not, no user will ever match.

3. The policy effect and matchers may behave unexpectedly when used together. The [policy_effect] section determines how multiple matched policies are combined into a single result. By default, each policy is allow, meaning one allow rule is enough to grant access. However, if you need to explicitly deny access for a user or team, use an eft column with priority(p.eft) || deny to create a clean and efficient policy table.

4. Missing role-graph rows can cause issues with the g function. The policy needs both parts to function correctly: the policy definition (p) and the role graph (g). For example, if alice belongs to the 'admin' role and wants to read '/data read', both the policy and role graph must be defined as p, admin, /data, read and g, alice, admin. If this role-graph row is missing, alice will not be able to match the '/data read' rule.

5. The cache may not update when refreshing the enforcer. If you use the syncedCachedEnforcer, updating the policy but still receiving the same enforce result usually means the cache was not refreshed. This issue is unrelated to the rules in model.conf. First, check the cache, and then revisit the model.conf file.