On 02/01/2014, at 14:35, Benoit Chesneau <[email protected]> wrote:
> On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <[email protected]> wrote: > >> Happy 2014 @ the list, >> >> there is no document level (or even worse attribute level) access control >> mechanism implemented in couched at this time, please correct me if I am >> wrong. Any type of document level access control introduces problems with >> either information leaking aggregate/reduce functions or plain wrong query >> results. It does not matter if implemented inside couchdb or elsewhere. > > > > not sure what you mean there. When using aggregate functions, e.g. count, counting all documents results either in leaking information (in case documents are counted that you do not have read access to) or the result is wrong (count reveals 2 documents, but in the db are much more). From a users point of view, it does not matter wether this behavior is introduced by couchdb code or somewhere else. In a lot of cases this is even what the user expects. For the App-developer it might be handy to have some functionality inside couchdb to avoid an external access control layer. validate_read might just be such a handy function. Filtering out GET (read) request on the http layer based on some document attributes might be helpful in some other cases. > > >> Anyhow, many applications require access control, maybe we should collect >> some ideas, best practices or implement some helping functions, such as >> validate_read, rewrite/vhost layer, etc. >> > You mean like : > > https://github.com/refuge/rcouch/wiki/Validate-documents-on-read > > ? > > yes > > >> Keno >> >> On 02/01/2014, at 13:27, Stanley Iriele <[email protected]> wrote: >> >>> Correct me if I'm wrong here... If every doc had some meta info with >> it... >>> And every URL rewrite went to a show or list function...couldn't you use >>> the sec object passed on the request object to get what you want?... Or >>> pass in some application level user credentials... Granted that doesn't >>> sound very elegant >>> On Jan 2, 2014 7:22 AM, "Robert Newson" <[email protected]> wrote: >>> >>>> >>>> It doesn’t achieve the same effect, though, the virtual host + url >>>> rewriter is not an access control mechanism. You’re still granting >>>> database-wide read permissions to the user. >>>> >>>> B. >>>> >>>> >>>> On 2 Jan 2014, at 09:09, Florian Westreicher Bakk.techn. < >>>> [email protected]> wrote: >>>> >>>>> I put a design doc behind a desk record / virtual host, that should do >>>> the trick. The user that is used by the app is read only >>>>> >>>>> Robert Newson <[email protected]> wrote: >>>>>> "there’s no notion of read-protection in CouchDB." >>>>>> >>>>>> There’s no document level read protection, but you can certainly grant >>>>>> or deny read access to users on a per database basis. That’s by design >>>>>> due to the ease that information could leak out through views >>>>>> (particularly reduce views). The restrictive proxy approach is >> brittle, >>>>>> it requires that you know all the URL patterns to block and keep them >>>>>> up to date when you upgrade CouchDB. It can work, it’s just not >>>>>> awesome. >>>>>> >>>>>> B. >>>>>> >>>>>> . >>>>>> >>>>>> On 1 Jan 2014, at 20:47, Jens Alfke <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> On Dec 31, 2013, at 1:44 AM, meredrica <[email protected]> wrote: >>>>>>> >>>>>>>> I expose CouchDB directly to mobile clients and wanted to hide some >>>>>>>> information from them. >>>>>>> >>>>>>> You can’t really do that; there’s no notion of read-protection in >>>>>> CouchDB. >>>>>>> As a workaround you can put CouchDB behind a proxy or gateway, and >>>>>> restrict the URL patterns that clients are allowed to send. >>>>>>> >>>>>>> —Jens >>>>>>> >>>>> >>>>> -- >>>>> Sent from Kaiten Mail. Please excuse my brevity. >>>> >>>> >> >>
