Access Rule Priority
Below you will find a description on some of the details about how rules are processed in ARDIs access control system.
All Matching Rules Apply
If you have multiple paths that apply to a single URL, only one of those paths have to fail in order to deny access.
For example, if you have a URL of /admin/properties/list, and you've got the following rules…
| Path | Rules |
|---|---|
| admin/ | Must be an admin-level user |
| admin/properties/list | Must be in the local network |
Then your user will have to meet both rules in order to be given access. If either rule is not met, access is denied.
Rule Order
Path rules are processed in order from the most complex to the least complex.
This generally means that longer rules (ie. admin/properties/list) will be processed before more general ones.
Terminating Early
There are rare instances that you might want to allow access to a resource that is being blocked by a more general rule. For example, what if you wanted to give users access to the /admin/properties/list page in the example above?
You can do this by adding 'terminal: true' to any one of the rules in the group.
If a terminal rule is valid, rule processing will end immediately - other matching paths won't be processed.
{ "paths": { "admin/": "admin_only", "admin/properties/list": "allow_local_user" }, "groups": { "admin_only": { "type": "userlevel", "level": "admin" }, "allow_local_user": { "type": "whitelist", "list": ["127.0.0.1"], "terminal": true } }
Because the 'path' rules will be processed in order of longest-path to shortest-path, the rule for admin/properties/list will be run first. Since it's a terminal rule, the tests will immediately stop once the rule is matched. The user will have access, even though they aren't an administrator.