On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <keno.kuhlm...@gmx.de> 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. > 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 ? > Keno > > On 02/01/2014, at 13:27, Stanley Iriele <siriele...@gmail.com> 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" <rnew...@apache.org> 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. < > >> st...@meredrica.org> 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 <rnew...@apache.org> 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 <j...@couchbase.com> wrote: > >>>> > >>>>> > >>>>> On Dec 31, 2013, at 1:44 AM, meredrica <st...@meredrica.org> 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. > >> > >> > >
