Re: [basex-talk] basex SERVERHOST
On Fri, 2012-12-21 at 21:54 -0500, Liam R E Quin wrote: > How do I use SERVERHOST in ~/.basex (or elsewhere) to get basex to > listen on the given PORT only on localhost (127.0.0.1) and not on > externally-visible IP addresses? > > Setting SERVERHOST and HOST to localhost does not seem to accomplish > this. To answer my own question, it's the .basex file in the BaseX distribution directory that is read, not the one in the user's home directory. There's also an attmept to read .basex in the directory from which the basex server (or client) was run, but that's not in general the home directory. > > Thanks! > -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] basex SERVERHOST
How do I use SERVERHOST in ~/.basex (or elsewhere) to get basex to listen on the given PORT only on localhost (127.0.0.1) and not on externally-visible IP addresses? Setting SERVERHOST and HOST to localhost does not seem to accomplish this. Thanks! -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] RFE: Turning off parts of the BaseX REST interface
I am building some Web-based services for a project I'm involved with, using the BaseX REST interface, and the experience has given me an idea for a possible enhancement to BaseX. It's extremely convenient for development to be able to issue arbitrary queries from the REST interface, but in my role as part-time system administrator and worrier about security, the REST 'query', 'command', and 'get' operations worry me to death. I am happy for the user access control provided by the GRANT command, and I find myself thinking it would be even nicer to have more control. I am happy to discover by experiment that a user with READ access only to a single database sees only that database name when they issue the the default GET request (http://hostname:8984/rest). When I allow my security paranoia full sway, I find I would like to be able to ensure that only authorized users can - perform arbitrary queries using the 'query' or 'command' interfaces - perform particular queries using the 'run' interface Concretely, in this case I would like to be able to create a user for restricted access, which I'll call PUBLIC for now, and ensure that a user who presents the PUBLIC userid and password - cannot fetch any data using the GET interface - cannot run queries using the rest:query interface - cannot run commands using the rest:command interface - can run only specified modules from the HTTPPATH directory (so we can limit the portions of the database we expose to the PUBLIC user -- I think of this as very roughly analogous to being able to limit a SQL user to particular views instead of to the underlying base tables) Of course, by running a packet filter we can ensure that the BaseX server only receives packets from (or: purporting to be from) the project's host, and we can keep the user password for the PUBLIC user secret in what I believe is the usual way (it's there in the source of the PHP module, but web users don't get to see the source of the module). The restrictions I have in mind would serve the purpose of attempting to limit the damage an adversarial user could cause if the user credentials were exposed or (in the case of limiting users to specific modules) if an adversary were able to add modules to the HTTPPATH directory. Disclaimer: I am not a security expert, just (at the moment) a worrier. You will surely be able to get advice from people who understand security issues better than I do. Thank you again for this extremely helpful software. -- * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] server / GUI synchronization and data safety
At various points in the documentation, it is observed that the BaseX server, the BaseX client, and the GUI interface all run in different virtual machines, so the GUI and the server's databases are not synchronized. In the GUI of BaseX 7.3, I see an optional Server Administration on the Database menu, which carries the warning Warning: The client/server architecture and the GUI are not synchronized. The same database should not be opened from clients and the GUI. Does this mean that it's safe to run both the server and the GUI as long as they have different databases open? (It doesn't say that; it says it's unsafe if they have the *same* database open. You see how timid warnings can make a user!) Also - in my case it would be convenient to be able to open the GUI and do some work while the BaseX HTTP server is running. If the HTTP server handles a request directed at database X, does that database remain open indefinitely or is it closed when the request has been handled? That is, is it safe to work with database X as long as I don't pass requests against X to the HTTP server at the same time/ And third - if neither the HTTP server nor the GUI are performing any updates, but only retrievals from the database, does the warning still apply, or is read-only access from multiple instances of BaseX actually safe? (I ask because if I need to shut down the HTTP server every time I want to launch the GUI to experiment with a new function, and then shut down the GUI so I can launch the HTTP server and work on the Web interface to the new function, then I am going to want to find a more convenient way of starting and stopping the HTTP server than going into a terminal window and running the shell script.) Thank you! -- * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] Release BaseX 7.5 – The BaseXMas Edition
Dear subscribers, yes, it has been quite a while… Which is why we are even more excited to finally announce the release of BaseX 7.5, the BaseXMas Edition, our XML Database and XQuery Processor! Here are the latest features and changes: XQUERY UPDATE - bulk updates are now much faster than before - insert and replace operations take much less memory - databases can now be created via XQuery and db:create() GUI TEXT EDITOR - a fast and flexible search/replace panel has been added - error highlighting has been extended to XML files - the editor was improved for editing arbitrary text files XQUERY 3.0 - the code has been aligned with latest changes in the specs - HTML5 support has been updated WEB APPLICATIONS - new modules have been added: Request, Session, Sessions - logging has been revised and extended to HTTP requests - SSL support added, switched to Jetty 8 - all operation modes have been unified and simplified - RESTXQ elements added to simplify forwarding and redirects CORE FEATURES - improved stability of concurrent read/write operations - the INSPECT command performs database sanity checks - EXECUTE triggers the execution of command scripts Numerous other things have happened, which you can look up in our documentation (http://docs.basex.org). 2012 has been a great year for BaseX, which is why we are very confident that you can expect many more open source versions of our product in the future! Thanks for reading; we are looking forward to all your feedback, Christian BaseX Team 2012 PS: If you haven’t registered yet… Don’t forget to join our XMLPrague User Meeting (http://lanyrd.com/2013/basex-users-meetup-xml-prague/)! ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Spatial XQuery
Hi all, Also about the Geo module and supporting formats, some libraries, like the newer versions of GeoTools (version 8.0 or newer), supports other formats of Geo Spatial data, that would be way a to expand this module in the future. Right now I am checking it to see how it works :) Regards Masoumeh -- On Thursday, December 20, 2012 17:06 CET, Christian Grün wrote: > Dear David, > > thanks for your request. Yes, one of our members (Masoumeh) is in fact > working on an implementation of the Geo Module (for GML2), and it may > get finished in Januar or February. It will closely resemble Zorba’s > implementation, and we think about proposing some updates to the > official EXPath spec, which is rather spartan when it comes to typing > issues, error handling, etc. > > As you indicated, linear search will then be supported out of the box. > Indexing the data would be the next exciting step, but we haven’t made > any concrete plans on when this will happen yet. Maybe anyone else out > there?… > > Hope this helps for the moment, > Christian > ___ > > > Hi Basex-ers > > > > I am new to the list but have been working with basex for a few weeks now. > > We are using basex to search ISO 19115 geospatial metadata. The full text > > search is simple and works better than any of the existing purpose built > > catalog tools we have worked with so far. > > > > I am very interested in the pervious thread on Spatial Xquery. > > https://mailman.uni-konstanz.de/pipermail/basex-talk/2012-January/002484.html > > I am looking over the Geo Module geospatial API today, and also at Zorba's > > Geo Module implementation. Has the Basex community made an further progress? > > > > The API is the first issue and so far the Geo Module definition looks > > great. If linear search using the existing attribute indexes is all that is > > available now, that is fine. It would be fantastic to write a geo spatial > > index to support that API in basex in the future. What type of indexes have > > you considered? I would think an Rtree would probably be best for > > supporting that API. > > > > This email is essentially a status query – as I work on this over the next > > week or two we can start new threads for specific topics. > > > > > > David Stuebe > > > > Scientist & Software Engineer – RPS ASA > > > > 55 Village Square Drive > > South Kingstown, RI 02879-8248 > > > > Tel: +1 (401) 789-6224 > > > > Email: david.stu...@rpsgroup.com > > www: asascience.com | rpsgroup.com > > > > A member of the RPS Group plc > > > > > > ___ > > 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
