couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Disabling doc include
Date Thu, 02 Jan 2014 13:35:00 GMT
On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <keno.kuhlmann@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 <siriele2x3@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" <rnewson@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. <
> >> stuff@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 <rnewson@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 <jens@couchbase.com> wrote:
> >>>>
> >>>>>
> >>>>> On Dec 31, 2013, at 1:44 AM, meredrica <stuff@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.
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message