Changes

* If several permission functions are available that match the user request, all of them will be called one by oneafter another. The function with the shorted shortest path argument will be called first. Accordingly, in the example, if the {{Code|/main/admin}} URL is requested, all three security functions will be runin the given order.* If a security function raises an error or returns any result XQuery value (which can be e.g. a [[Web Module#web:redirect|redirection or any other XQuery value]] to another web page), no other functions will be invoked. This means that the actually invoked function that has been requested by the client will only be evaluated if all security functions yield no result or and no error.* As shown in the first function, the {{Code|%perm:check}} annotation can be combined with other RESTXQ annotations (, excluding {{Code|%rest:path}} and {{Code|%rest:error}}).* In the example, it is assumed that a logged in user is bound to a session variable (see further below).

The permission layer was designed to provide as much flexibility as possible to the web application developer. Some extreme cases: * It is possible to completely work without permission strings, and realize all access checks based on the request information (path, method, and properties returned by the [[Request Module]]).* Each It is also possible (but rather unhandy) to accompany each RESTXQ function can be accompanied by its individual security function. The bare minimum is a single {{Code|%perm:check}} function. Without this function, existing {{Code|%perm:allow}} annotations will be ignored.