Changes

Non-trivial web applications provide the ability for users to sign in and out{{Mark|Updated with Version 9. 3:}} User handling can will also be realized with session looked up in the request attributes (see e. g. the [[DBA]] code).

By default, RESTXQ code is run executed with admin permissions. However, as it is more interesting to know which user has called a function, the RESTXQ user string (which is {{Code|admin}} by defaultuser. As a result, and which this user will show up be displayed in the log data) will be overwritten by logs for all RESTXQ requests. In a web application with a custom user management, however, the value name of an {{Code|id}} session attribute. If the actual user who has sent a request path includes {{Code|/dba/}}, the {{Code|dba}} session attribute will be assignedis often more relevant.

If When log data is written during the processing of a RESTXQ function, the following function is called more than once, {{Code|joe}} will appear looked up as user in the second and subsequent log entriesfollows:

<pre class="brush# The current request is checked for an {{Code|id}} attribute. The attribute can be assigned via RESTXQ and the {{Function|Request|request:xquery">import module namespace Session = 'http://basexset-attribute}} function, and it is the recommended approach for stateless requests as all request attributes will be dropped after the finalization of a request.org/modules/session';declare %rest:path('/# If none is found, the {{Code|id}} attribute is looked up in the current user session-id') function local:f() . The attribute can be assigned via {{ Function|Session|session:set}} ('id', 'joe'see e. g. the [[DBA]] code for sessions and user handling). If the request path contains a {{Code|dba}} segment, 'I am Joe'a {{Code|dba}};session attribute will be looked up instead.</pre># If none is found, the default path will be taken, and the user of the current database context will be included in the logs.