Permissions - Revision history

CG: Text replacement - "" to "

2023-12-01T16:35:43Z

Text replacement - "<syntaxhighlight lang="xquery">" to "<pre lang='xquery'>"

CG: Text replacement - "" to ""

2023-12-01T16:32:26Z

Text replacement - "</syntaxhighlight>" to "</pre>"

CG: /* Authentication */

2022-07-25T13:39:49Z

Authentication

CG at 14:32, 27 February 2020

2020-02-27T14:32:23Z

CG: /* Checking Permissions */

2019-04-16T12:41:18Z

Checking Permissions

CG at 12:44, 10 July 2018

2018-07-10T12:44:05Z

CG at 11:12, 24 May 2018

2018-05-24T11:12:57Z

CG: /* Authentication */

2018-01-19T13:04:47Z

Authentication

CG: /* Checking Permissions */

2018-01-19T13:04:20Z

Checking Permissions

CG: /* Checking Permissions */

2018-01-19T12:48:38Z

Checking Permissions

@@ Line 16: / Line 16: @@
 With the {{Code|%perm:allow}} annotation, one or more permission strings can be attached to a RESTXQ function:
-<syntaxhighlight lang="xquery">
+<pre lang='xquery'>
 (:~ Login page (visible to everyone). :)
 declare
@@ Line 74: / Line 74: @@
 An example:
-<syntaxhighlight lang="xquery">
+<pre lang='xquery'>
 import module namespace Session = 'http://basex.org/modules/session';
@@ Line 126: / Line 126: @@
 The following lines of code complete the image:
-<syntaxhighlight lang="xquery">
+<pre lang='xquery'>
 declare
    %rest:path("/login-check")

@@ Line 54: / Line 54: @@
    </html>
 };
-</syntaxhighlight>
+</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.
@@ Line 105: / Line 105: @@
    return web:redirect('/main')
 };
-</syntaxhighlight>
+</pre>
 Some notes:
@@ Line 147: / Line 147: @@
    web:redirect("/")
 };
-</syntaxhighlight>
+</pre>
 For a full round trip, check out the source code of the [[DBA]] that is bundled with BaseX.

@@ Line 120: / Line 120: @@
 There are numerous ways how users can be authenticated in a web application (via OAuth, LDAP, …). The approach demonstrated on this page is pretty basic and straightforward:
-* A login HTML page allows you to enter your credentials (user name, password).
+* A login HTML page allows you to enter your credentials (username, password).
 * A login check function checks if the typed in data matches one of the database users. If the input is valid, a session id will be set, and the user will be redirected to the main page. Otherwise, the redirection points back to the login page.
 * A logout page deletes the session id.

@@ Line 16: / Line 16: @@
 With the {{Code|%perm:allow}} annotation, one or more permission strings can be attached to a RESTXQ function:
-<pre class="brush:xquery">
+<syntaxhighlight lang="xquery">
 (:~ Login page (visible to everyone). :)
 declare
@@ Line 54: / Line 54: @@
    </html>
 };
-</pre>
+</syntaxhighlight>
 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.
@@ Line 74: / Line 74: @@
 An example:
-<pre class="brush:xquery">
+<syntaxhighlight lang="xquery">
 import module namespace Session = 'http://basex.org/modules/session';
@@ Line 105: / Line 105: @@
    return web:redirect('/main')
 };
-</pre>
+</syntaxhighlight>
 Some notes:
@@ Line 126: / Line 126: @@
 The following lines of code complete the image:
-<pre class="brush:xquery">
+<syntaxhighlight lang="xquery">
 declare
    %rest:path("/login-check")
@@ Line 147: / Line 147: @@
    web:redirect("/")
 };
-</pre>
+</syntaxhighlight>
 For a full round trip, check out the source code of the [[DBA]] that is bundled with BaseX.

@@ Line 70: / Line 70: @@
 ** {{Code|path}}: Original path of the client request.
 ** {{Code|method}}: Method of the client request ({{Code|GET}}, {{Code|POST}}, …).
-** {{Mark|Added with Version 9.1}}: {{Code|authorization}}: Value of the HTTP Authorization header string; may be empty.
+** {{Code|authorization}}: Value of the HTTP Authorization header string; may be empty.
 An example:

@@ Line 67: / Line 67: @@
 ** If no path argument is specified, {{Code|/}} is assigned instead.
 * A variable can be specified in the second argument. A map with the following keys will be bound to that variable:
-** {{Code|allow}}: Permission strings attached to the requested function.
+** {{Code|allow}}: Permission strings attached to the requested function; may be empty.
 ** {{Code|path}}: Original path of the client request.
 ** {{Code|method}}: Method of the client request ({{Code|GET}}, {{Code|POST}}, …).
 An example:
@@ Line 151: / Line 152: @@
 =Changelog=
 The Module was introduced with Version 9.0.

@@ Line 1: / Line 1: @@
 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.
+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. The light-weight permission layer simplifies permission checks a lot:
 * Permission strings can be attached to RESTXQ functions.

@@ Line 119: / Line 119: @@
 =Authentication=
-There are numerous ways how users can be authenticated in a web application (via OAuth, LDAP, …). The approach demonstrated in this article is pretty basic and straightforward:
+There are numerous ways how users can be authenticated in a web application (via OAuth, LDAP, …). The approach demonstrated on this page is pretty basic and straightforward:
 * A login HTML page allows you to enter your credentials (user name, password).

@@ Line 110: / Line 110: @@
 Some notes:
-* If several permission functions are available that match the user request, all of them will be called one by one. The function with the shorted path argument will be called first. Accordingly, in the example, if the {{Code|/main/admin}} URL is requested, all three security functions will be run.
+* If several permission functions are available that match the user request, all of them will be called one after another. The function with the shortest path will be called first. Accordingly, in the example, if the {{Code|/main/admin}} URL is requested, all three security functions will be run in the given order.
-* If a security function raises an error or returns any result (which can be a redirection or any other XQuery value), no other functions will be invoked. This means that the actually invoked function will only be evaluated if all security functions yield no result or error.
+* If a security function raises an error or returns any XQuery value (e.g. a [[Web Module#web:redirect|redirection]] to another web page), no other functions will be invoked. This means that the function that has been requested by the client will only be evaluated if all security functions yield no result 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}}).
+* 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)
+* 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:
+The permission layer was designed to provide as much flexibility as possible to the web application developer: 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]]). It is also possible (but rather unhandy) to accompany each RESTXQ function 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.
 =Authentication=