====Access Rule Priority====

Below you will find a description on some of the details about how rules are processed in ARDIs [[pathsecurity|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. 

<code javascript>
{
   "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
        }
   }
</code>

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.