- BaseX-Talk - mailman.uni-konstanz.de

webdav issue using oxygen
by Maximilian Gärber 22 Mar '12

22 Mar '12

Hi, following the steps on http://docs.basex.org/wiki/Integrating_oXygen for accessing resources via webdav, I guess it should be possible to change and save xml files. Doing so, actually empties the db and adds a "RAW" xml resource to it. This happens with the latest Snapshot (7.2). Any other Oxygen users out there? Regards, Max

2 1

Ask about BaseX event for more than one context
by truc.cam＠emotive.de 22 Mar '12

22 Mar '12

Dear BaseX team, Please see the attachment. When I use events for 2 contexts, just the first one can notify.If the notification of the 2rd context happens, the result should be "1 2 3 4". If I replace "xquery2.execute(context2)" by "xquery2.execute(context1)", I will receive right result. But this is not what I want to do. Thanks in advance. Best regards

2 1

REST API now returning exceptions as HTML?
by Charles Duffy 22 Mar '12

22 Mar '12

Howdy -- Historically, the BaseX REST API has handled exceptions by returning only the exception content itself. I just ran a build against current SVN, and received the following: <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>Error 400 Stopped at line 1, column 75: [XPST0017] Unknown Java function 'net.dyfis.svnkit_wrapper.SvnWrapper.cat(...)'.</title> </head> <body><h2>HTTP ERROR 400</h2> Problem accessing /rest. Reason: <pre> Stopped at line 1, column 75: [XPST0017] Unknown Java function 'net.dyfis.svnkit_wrapper.SvnWrapper.cat(...)'.</pre><hr />Powered by Jetty:// </body> </html> Is this now desired/documented/ongoing behavior?

2 1

Debugging jar loading (Java interface)
by Charles Duffy 21 Mar '12

21 Mar '12

Howdy -- I'm trying to include (and use) a jar in a package, and not having any luck of it just yet. Could I get any guidance on what I might be missing here? === BEGIN expath-pkg.xml <package xmlns="http://expath.org/ns/pkg" spec="1.0" name="http://dyfis.net/svnkit-wrapper" abbrev="svnkit" version="0.1"> <title>Subversion Wrapper</title> <xquery> <namespace>http://dyfis.net/svnkit-wrapper</namespace> <file>svn.xq</file> </xquery> </package> === END expath-pkg.xml === BEGIN basex.xml <package xmlns="http://expath.org/ns/pkg"> <jar>svnkit-wrapper.jar</jar> <class>net.dyfis.svnkit_wrapper.SvnWrapper</class> </package> === END basex.xml === BEGIN svnkit/svn.xq module namespace svnkit = "http://dyfis.net/svnkit-wrapper"; declare namespace j="java:net.dyfis.svnkit_wrapper.SvnWrapper"; declare function svnkit:cat($path as xs:string) as xs:string { j:cat($path) }; declare function svnkit:cat($path as xs:string, $rev as xs:integer) as xs:string { j:cat($path, $rev) }; === END svnkit/svn.xq ...where "svnkit-wrapper.jar" contains a thin wrapper around TMate's SVNKit library, allowing direct access to Subversion resources through a simpler API (providing static functions only, abstracting away session management and the like). However, when I try to call svnkit:cat($subversion_url), the following is returned: [XPST0017] Unknown Java function 'net.dyfis.svnkit_wrapper.SvnWrapper.cat(...)'. I can call net.dyfis.svnkit.wrapper.SvnWrapper("") through Jython and other JVM-based interpreters, so I'm confident that the jar correctly exposes it. Any pointers on what I might be doing wrong in the packaging?

1 2

Re: [basex-talk] Use of unsalted password hashes
by Dimitar Popov 18 Mar '12

18 Mar '12

Am Sonntag, 18. März 2012, 12:16:48 schrieb Charles Duffy: > On Sun, Mar 18, 2012 at 10:16 AM, Dimitar Popov < > Dimitar.Popov(a)uni-konstanz.de> wrote: > > > Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy: > > > Caching accepted username/password pairs in RAM, and maintaining a > > > separate pool using the credentials for each such pair, would _work_, > > > but it would mean that you'd have to be careful not to let the memory > > > that information is stored in get swapped to disk -- writing users' > > > passwords to disk, even by way of the OS's swap operations, being a > > > serious no-no. > > > > The pairs username/password can be, of course, hashed and additionally, > > swap > > partitions can be encrypted, if such a level of security is required. > > > > Hashing could work, but adds a requirement that only basic auth be > supported. Given the number of other credential-proving mechanisms in the > world (Kerberos, NTLM, etc), this seems a very unfortunate limitation to > place on future development. > > As for encrypted swap -- in a typical commercial environment, that's > outside of the dev team's control unless they bother to do a great deal of > paperwork and politics; in short, not an acceptable solution. > > AFAIK, JCA provides a keystore mechanism, which I guess, provides enough > > means > > of protection against steal. I'm, however, too lazy to thoroughly read the > > JCA > > guide [1], but the first which comes to my mind is for example, external > > storage of keys. > > > > Again, to make that keystore secure, you're creating requirements that the > typical user won't implement. Better to design things to be secure > out-of-the-box, rather than "secure if only you do A, B, C and D". Well, then it seems after all, that the token alternative provides the highest degree of flexibility and security :) I guess, if there are no other suggestions, it should be discussed how to implement it. Regards, Dimitar

1 0

Use of unsalted password hashes
by Charles Duffy 18 Mar '12

18 Mar '12

Howdy -- I'm a bit concerned about storing password hashes unsalted -- compared to a salted hash, this makes a stolen database easier to retrieve user passwords from, dangerous if users use their passwords for other purposes as well. Would salting (and perhaps stretching) the hashes be considered a reasonable feature to support in the future?

4 16

Setting the context item via the native protocol
by Charles Duffy 17 Mar '12

17 Mar '12

Howdy -- Right now, I'm aware of two ways to set the context item via the native protocol: (1) Insert a "declare context item" header into the document - Disadvantage: Should only work when XQUERY3 is true - Disadvantage: Modifies line/column references for errors received - Disadvantage: Hard to ensure that user-provided XML document will evaluate to itself in XQuery (security risk) (2) Use the "CS" ["Context Set"] command - Disadvantage: Requires a database to be open (why?) - Disadvantage: Hard to ensure that user-provided XML document will evaluate to itself in XQuery (security risk) Is there a better approach?

2 8

REPOPATH prefixed twice on current snapshots?
by Charles Duffy 17 Mar '12

17 Mar '12

In my .basex file: REPOPATH = /home/cduffy/local/opt/basex-data/repo ...and running repo:list() shows my local package, with namespace http://dyfis.net/ as installed, but trying to use anything from it leads to an error similar to the following: releng.db.basex.rest.RemoteException: [XQST0059] Could not retrieve module '/home/cduffy/local/opt/basex-data/home/cduffy/local/opt/basex-data/repo/http-dyfis.net-0.1.140101/dyfis/reporting.xq'. This is happening with a local build of 230e16551cf397def9e6c59044ff605e48908e1c (current master on github).

2 8

after upgrading one big disaster
by jidanni＠jidanni.org 17 Mar '12

17 Mar '12

All I know back in December the Makefile and programs in http://radioscanningtw.jidanni.org/images/radioscanningtw/maps/ worked fine. Now with BaseX 7.1.1 it is one big disaster and will take days to rewrite.

3 6

Any way to persist OutputStream in DiskData?
by Dave Glick 16 Mar '12

16 Mar '12

Hi, I've been doing some profiling recently and noticed one area in particular that appears to be using a lot of cycles. In calls to DiskData.write() the final DataOutput.close() call results in 20% - 40% of overall execution time in a variety of cases. The following screen capture shows the aggregated call stack (though it might look a little funny since this is the cross-compiled version used for Nxdb). Admittedly, this is probably an issue that just impacts me. Based on the trace, I suspect the issue is related to the releasing of handles rather than the actual disk writes (though I could be wrong - I'm not entirely sure what the cross-compiler does behind the scenes to support Java file descriptors). In any case, my question boils down to wondering if there is a way to force the DiskData class to use a persistent DataOutput instance instead of creating and closing a new one for every write? Instead, could a DataOutput be kept open until the database is "unpinned" and simply flushed on each write? Would this cause any problems with the current GUI, server, etc. uses? Thanks, Dave

3 4