Application Boundaries Enforcer (ABE) NoScript （(安)NoScript应用程序边界执行者）.pdfVIP

Application Boundaries Enforcer (ABE) NoScript Module Rules Syntax And Capabilities Version 1.2.2 – 2017-07-27 Author: Giorgio Maone – giorgio@ Table of Contents 1. Ruleset, Rules and Predicates2 1.1. Actions3 1.2. Methods4 1.3. Resources5 2. Examples6 3. EBNF Grammar Reference7 ABE Rules Syntax and Capabilities v. 1.2.2 p. 1/7 1. Ruleset, Rules and Predicates This is a functional description of the ABE rules capabilities. For a formal syntactic specification please see 3. EBNF Grammar Reference. ABE rules are meant to enforce specific actions modifying HTTP requests identified by their destination site (an URI pattern), and optionally by their HTTP method and/or their origin site. Rules are collected in a ruleset, which is just a text file containing a list of rules and optionally comments: rule [[#comment] [rule] ...] Comments are ignored: they can be placed anywhere, start with a # character and always finish at the end of the line. Rule priority goes down from top to bottom: processing stops as soon as a rule matches current request. Therefore highest priority (most specific) rules should be placed topmost. A rule looks like this: Site resource predicate [predicate ...] A resource is typically an URI pattern (literal, glob or regexp) designing a request destination (site), or a wildcard token such as ALL or SELF. A predicate is made of an action (e.g. Allow, Deny) which must be enforced on certain requests. Requests are identified by their HTTP methods (e.g. GET, POST or ALL) and optionally by their origin, specified as “from resource ” : action [method[ method...]] [from resource] A missing method or from clause implies ALL or from ALL , respectively. Predicate priority goes down from top to bottom: proc