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.a...@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.gr...@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 >> > >
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
