The change is not a problem for me, but I am not a security expert ;-) However if it stays then I guess it means the -U and -P options to basexhttp are being silently ignored.
I think something like the existdb approach would be more what I would expect. The ability to config a default http user with reduced permissions, and then a way to change the user associated with the session e.g. session:set-current-user http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xqu...
/Andy
On 12 January 2015 at 17:48, Christian Grün christian.gruen@gmail.com wrote:
Exactly. In our own RESTXQ applications, we haven't experienced any case in which the restriction was useful so far. But I guess, this is different in (some of) your applications?
We could think about reverting this change, and specifying admin/admin as default in web.xml for the RESTXQ service instead. Do you think that would make sense?
Christian
On Mon, Jan 12, 2015 at 6:44 PM, Andy Bunce bunce.andy@gmail.com wrote:
So does this mean all restxq code always runs as admin and can do
anything?
On 12 Jan 2015 17:37, "Christian Grün" christian.gruen@gmail.com
wrote:
Hi Andy,
With BaseX 8.0, no authentication is required anymore when using RESTXQ, because all code to be executed is defined server-side. This continues to be different with REST and WebDAV.
Hope this helps? Christian
On Mon, Jan 12, 2015 at 6:09 PM, Andy Bunce bunce.andy@gmail.com
wrote:
Hi, Just investigating user handling, I am using the latest snapsnap.
I start basexhttp with -U guest -P guest and/or I set org.basex.user and org.basex.password in web.xml
Sometimes I have created a user ( guest with password guest) and permission none via dba. Sometimes I have deleted the guest user.
In all cases I appear to be able to run restxq queries and in those queries read from databases.
Am I misunderstanding something here?
/Andy