That code got a little garbled. I meant: client:connect('localhost', 1984, $user, $password) ! client:query(.,$src)
See http://docs.basex.org/wiki/Client_Module#client:query
On Fri, Jun 28, 2013 at 11:52 AM, Andy Bunce bunce.andy@gmail.com wrote:
As someone coming at this from the other direction - I would like to allow dynamic execution of anything (given the appropriate passwords, of course). I am trying to implement something similar to eXide [1] to run on an Android phone. I am using
client:connect('localhost', 1984, 'admin', 'admin') ! client:query(.,$src) client:connect('localhost', 1984, 'admin', 'admin') !
to execute arbitrary strings from a RESTXQ application. This does allow updating expressions.
I was surprised, but not too concerned, that "file:list('.')" requires create permission. I could not find this, or similar information in the Wiki. It would be a useful addition to document it there.
I believe, at the Java level, these permissions are described using an annotation and I wonder if there would be value in surfacing these as a custom BaseX annotation in the module function stubs in etc\modules and even allowing their use with pure XQuery code?
Regards /Andy
[1] http://exist-db.org/exist/apps/eXide/docs/doc.html
On Fri, Jun 28, 2013 at 9:20 AM, Christian Grün <christian.gruen@gmail.com
wrote:
Can you provide more information on how this is implemented on the BaseX site?
[…] I was worried about the rest:query interface: I can make my PHP proxy do all the checking I would have done with cqi:nanny-says-ok(), but I can't prevent an adversary from sending an HTTP request directly to the BaseX server and bypassing the PHP proxy -- so I wanted to do my checking in XQuery.
I’d like to, but I must admit that the existing implementation includes some irrelevant indirections, which is one of the reasons (beside time constraints) why we didn’t make it public so far. The general principle is simple, however: the query is sent to the plain REST service of a remote BaseX HTTP Server, and the chosen user has read-only permissions. If you want to avoid that the BaseX server is visible and can be controlled from outside, you can e.g. restrict the SERVERHOST option to localhost [1,2].
Maybe this already solves part of the challenge? Christian
[1] http://docs.basex.org/wiki/Options#SERVERHOST [2] http://docs.basex.org/wiki/Startup_Options#BaseX_Server _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk