I have no idea if this fits in to your plans, but I wanted to record our use case as
it may be one that you want to support.
We want to make use of couchdb-lucene in an environment where can't fully restrict access to its port. Basically we want to add full-text-search capabilities to desktopcouch. We think we have a solution to running up a private instance of couchdb-lucene that can talk with the private couchdb, but we are stuck on security.
In this environment couchdb-lucene would just bind to localhost, but we can't stop other users on the same machine from reaching its port, and that could lead to information disclosure at the least.
Therefore we want some way for couchdb-lucene to authenticate requests so that it can only be used by the user that it is intended for.
After some discussion with aquarius he suggested that having couchdb-lucene listen on an AF_UNIX socket would be perfect, as we can use UNIX DAC to lock down access, and as all
communication from couchdb to couchdb-lucene is mediated by the external helper it doesn't have to be over TCP. However, this doesn't fit too well with the new externals API
as couch itself would have to proxy over an AF_UNIX socket.
I assume that you plan to move to the new API when it is merged?
Another alternative would then be to use the same strategy as we use for desktopcouch, which is to use oauth-signed requests, where the credentials are available to any process running as the target user (and root). If couchdb-lucene could be configured to only accept oauth signed requests too that would be great. With the new API it might even be reasonable to have it use the same oauth db, and so we can sign all requests with the same credentials, but given that the nonce db etc. wouldn't be shared that may not be reasonable.
Do you have any other suggestions? Does any of this fit in with your plans for couchdb-lucene?
Incorporating an authentication mechanism to c-l interests me but I am the sole contributor to the project and my time is limited. I would certainly take a patch to add some kind of authentication if you are working on it?
Assuming you're not, then I take your suggestion seriously and I expect it to get done at some point. Obviously I cannot commit to a timeframe.
Paul's proposed new externals method should allow authentication but I will raise that topic with him directly.
The current externals hook exposes the userCtx and secObj objects to couchdb-lucene, perhaps it's an easy fix?
Thanks for looking at this.
I'm not working on it right now, but clearly if it is important enough to me I should.
I don't think that we can use the userCtx passed by couchdb, as it isn't authenticated, and so easy enough to spoof.
I second the request, but in the meantime, I just went with this:
url = http://user:email@example.com:5984/
It works and since it's on the same server as couchdb and all application code I don't worry about security of this approach.