Changes

Jump to navigation Jump to search
34 bytes added ,  14:46, 19 January 2018
no edit summary
This page presents the web application permission layer of BaseX, which can be used along with [[RESTXQ]].
Non-trivial web applications require a user management: Users need to log in to a web site in order to get access to protected pages. ; Depending on their status (role, user group, …), they can be offered different views; etc.
With {{Version|9.0}} of BaseX, a light-weight permission layer has been added that simplifies permission checks a lot:
* permission Permission strings can be attached to RESTXQ functions, and.* permission With security functions , you can ensure that access to RESTXQ functions will only be granted if a client has to clients with sufficient permissions.
=Preliminaries=
</pre>
The permission strings may denote ids, users, user groups, applications, or any other realms. It is completely up to the user which strings are used, and which functions will be annotated. In the given example code, only the last function has a {{Code|%perm:allow}} annotation.
==Checking Permissions==
Functions that are marked with {{Code|%perm:check}} are so-called ''Security Functions''. These functions will be invoked before the actually requested function will be evaluated. Two arguments can be specified with the annotation:
* 1. A path argument can be specified with the as first argument. : * The security function will only be called if the path of the client request path starts with the given specified path. * In contrast to RESTXQ, all subordinate paths will be accepted as well. * If no path argument is specified, {{Code|/}} is assigned instead.* With the 2. A variable name can be defined as second argument, various permission-specific information can . A map with the following keys will be bound to a mapthat variable: * {{Code|allow}}: Permission strings attached to the requested function. * {{Code|path}}: Original path of the client request. * {{Code|method}}: Method of the client request ({{Code|GET}}, {{Code|POST}}, …).
An example:
* 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 map, which can be bound to a variable (in this example {{Code|$perm}}), has the following keys:
 
{| class="wikitable" width="100%"
|- valign="top"
! Key
! Description
|-
| {{Code|allow}}
| Permission strings attached to the requested function.
|-
| {{Code|path}}
| Original path of the client request.
|-
| {{Code|method}}
| Method of the client request ({{Code|GET}}, {{Code|POST}}, …)
|}
The permission layer was designed to provide as much flexibility as possible to the web application developer. Some extreme cases:
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu