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 15:50:51 GMT
Thanks Robert, Simon & Dave!

Its always difficult to realize that if the conclusion doesn't fit then the
assumption must be wrong. I was assuming that my TouchDB/CouchCocoa
replicator client had been passing the credentials of a remote_admin_user
to the remote_url all along but it turns out that this was simply a false
assumption.

Thanks to your explanation I could work back and figure out that the creds
had never been included before in a call and the db had always been open to
replication by anyone at all! Putting the reader role in was a stroke of
luck that should have helped me see this grave mistake right away ... but
instead I started blaming it for my troubles ... LOL, thanks for
straightening out my basics.

Cheers,
- Pulkit

On Thu, Jun 21, 2012 at 5:01 AM, Robert Newson <rnewson@apache.org> wrote:

>
> The replicator does not inherently have admin privileges (this would make
> our security model redundant). It has the privileges of the user you run it
> as, and can do only the things that that user can. This is why, for
> example, it's possible that design documents don't get replicated, because
> that requires _admin privilege on the target. Thus, there is no mystical
> interaction, the replicator is just a normal user automating the task of
> ensuring all changes from a source db are copied to a target db. To get a
> 401 means that the value in your "target" field did not include
> authentication details (or included incorrect authentication details) and
> that your target server has require_valid_user set to true.
>
> B.
>
>
> On 21 Jun 2012, at 01:57, Pulkit Singhal wrote:
>
> > 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