incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pulkit Singhal <pulkitsing...@gmail.com>
Subject Re: Replication and validate_doc_field
Date Thu, 21 Jun 2012 00:57:18 GMT
Right, so what I'm saying is that the replicator client is being run with
the creds of a super-duper-admin who inherently has _admin privileges.

When the same code is run against a DB without any reader roles, everything
works out. But when it is run against a DB with a reader role, it fails.

I'm hoping that someone will clarify the security constraints around how
replication behaves with db level security in 1.2.0

I already read the following tidbit in the wiki:
http://wiki.apache.org/couchdb/Replication#line-207
But it has more to do with the replicator DB itself rather than the DB
being replicated so I'm hoping someone can shed some documentation-worthy
light on how security works around a DB being replicated.

On Wed, Jun 20, 2012 at 5:03 PM, Robert Newson <rnewson@apache.org> wrote:

> The replicator is just a client, so if your validate_doc_update doesn't
> allow it to update, it won't be able to update.
>
> That said, 401 means you failed to pass a valid user:pass combination. You
> failed to *authenticate*, though the standard description of 401 is
> notoriously misleading.
>
> B.
>
>
> On 20 Jun 2012, at 22:38, Pulkit Singhal wrote:
>
> > Thanks for pointing out that mis-type, I was indeed referring to
> > validate_doc_update.
> > And I'm familiar with the wiki links and the general instructions around
> it
> > as well.
> > Perhaps I should explain the motivation behind this question.
> >
> > When I attempt to replicate from CouchDB 1.2.0 to TouchDB (another
> flavor),
> > I receive:
> > error (
> >    401,
> >    "401 unauthorized"
> > )
> > A little bit of trial and error showed that as long as I did NOT set
> > member-roles or member-names on the DB level security in futon ...
> > everything worked fine.
> >
> > So now have to wonder why this happens, why would db-member-level
> security
> > prevent an _admin from replicating? My 1st guess was that perhaps
> > validate_doc_update somehow now has a hand in replication as well so I
> just
> > wanted to check ... if that is not the root cause here then what could it
> > be?
> >
> > On Wed, Jun 20, 2012 at 3:34 PM, Dave Cottlehuber <dave@muse.net.nz>
> wrote:
> >
> >> On 20 June 2012 22:22, Pulkit Singhal <pulkitsinghal@gmail.com> wrote:
> >>> Does validate_doc_field method affect replication authN or authZ for
> >>> CouchDB 1.2.0?
> >>
> >> Hey Pulkit,
> >>
> >> I googled authN/Z and found authorisation and authentication. I checked
> >> the source and there's no validate_doc_field.
> >>
> >> A validate_doc_update function (VDU) is run on a single doc only, and
> >> has access to the proposed new doc as well as the current on-disk
> version,
> >> and the user context.
> >>
> >> So you can tell if the submitter of the update is authenticated or not,
> and
> >> you can use couchdb roles, or other custom javascript fields in your doc
> >> to decide to reject the docs or not.
> >>
> >> There's more info on both the wiki and the definitive guide on this too.
> >>
> >> A+
> >> Dave
> >>
>
>

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