[apologies - there was a typo in my previous message, please refer to this one instead] Hi, I'm running into a permissions error trying to use xquery:eval. I'm on BaseX 9.7.2. This is the error I get when running the query on the server using the REST service (using the default 'reader' user)... [basex:permission] No admin permission: xquery:eval($qString_50, map { "": db:open-pre("Modes", 0)}, map{"permission": "read", ... }) This is the line in the query which throws the error: let $set_combined := xquery:eval($qString, map{'': db:open($db)}, map{'permission': 'read'})
The query string itself, which is passed to eval is a very simple selection, for example: /Interchange/Object[Identification/ObjectName/Keyword/text() = "plate"]
Have I misunderstood the purpose of the permission option in xquery:eval? I assumed by setting it to 'read' it would ensure that anyone with read permission would be able to execute it. The query string itself shouldn't require higher permissions in order to be evaluated. Many thanksMarc M. Balston M: +44 7786 263 906
RegardsMarc M. Balston M: +44 7786 263 906
Hi Marc,
The invocation of xquery:eval requires admin privilegues; but if you are an admin user, you can decide under which permissions this query will be executed.
If you want to evaluate an XPath expression with a limited user and the REST API, it should be sufficient to supply this path as query:
http://localhost/rest/db?query=/path
You can also address and run a server-side query:
http://localhost/rest/db?run=xpath.xq
If you need to further process the results of a dynamic XPath query, you’ll probably need to switch to RESTXQ.
Your use case is inspiring, though: Maybe we could make xquery:eval more flexible and run it with the permissions of the current client. A client may then be allowed to further restrict the permission scope: If a client has 'read' permissions, (s)he could further restrict the permissions to 'none' (but not extend it to e.g. 'write').
I’ll have some more thought on that, as we currently don’t have any functions that have dynamic permissions at runtime.
Best, Christian
I’ll have some more thought on that, as we currently don’t have any functions that have dynamic permissions at runtime.
And it was easier than expected. Feel free to check out the latest stable snapshot [1].
Best, Christian
Wow, that was quick!That gives me another reason to upgrade to BaseX 10! Many thanksMarc M. Balston M: +44 7786 263 906
On Monday, 8 August 2022 at 16:15:16 BST, Christian Grün christian.gruen@gmail.com wrote:
I’ll have some more thought on that, as we currently don’t have any functions that have dynamic permissions at runtime.
And it was easier than expected. Feel free to check out the latest stable snapshot [1].
Best, Christian
Hi Christian, Although the string evaluated by xquery:eval will always be an XPath, that string is itself constructed within a rather complex query. The query accepts several parameters which are each used to construct individual XPath expressions. Originally the query was constructed so that each of these XPaths were evaluated immediately, by applying them to a common subset. This subset would then successively narrow as each parameter was applied. However, I realised that by constructing the complete XPath and applying it once through xquery:eval I could better leverage the optimisation of BaseX. This approach improved performance dramatically. It sounds like what I'm trying to do isn't possible currently, but I'd certainly appreciate it if it could be made possible in an update. Many thanksMarc M. Balston M: +44 7786 263 906
On Monday, 8 August 2022 at 15:49:38 BST, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
The invocation of xquery:eval requires admin privilegues; but if you are an admin user, you can decide under which permissions this query will be executed.
If you want to evaluate an XPath expression with a limited user and the REST API, it should be sufficient to supply this path as query:
http://localhost/rest/db?query=/path
You can also address and run a server-side query:
http://localhost/rest/db?run=xpath.xq
If you need to further process the results of a dynamic XPath query, you’ll probably need to switch to RESTXQ.
Your use case is inspiring, though: Maybe we could make xquery:eval more flexible and run it with the permissions of the current client. A client may then be allowed to further restrict the permission scope: If a client has 'read' permissions, (s)he could further restrict the permissions to 'none' (but not extend it to e.g. 'write').
I’ll have some more thought on that, as we currently don’t have any functions that have dynamic permissions at runtime.
Best, Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Marc Balston