Thank you for your answers I'll try with simple web services layer.

Le 23 sept. 2017 3:14 PM, "Stefan du Fresne" <ste...@medicmobile.org> a
écrit :

> None that I know of no. Ideally it would just work, but I think editing
> permissions for _users is effectively deprecated at this point.
>
> Really the only thing you can do is write a security layer yourself,
> either by wrapping CouchDB and converting those calls (after checking your
> own security) to be done by an admin user, or provide a separate API etc.
>
> Stefan
> > On 23 Sep 2017, at 13:40, max <maxima...@gmail.com> wrote:
> >
> > Thanks,
> >
> > Any workaround from configuration  ? I would like to avoid making more
> > couchdb admin...
> >
> > Le 23 sept. 2017 1:08 PM, "Stefan du Fresne" <ste...@medicmobile.org> a
> > écrit :
> >
> >> This is currently how it works yeah.
> >>
> >> I believe the current recommendation for user management is to
> effectively
> >> ignore the permissions matrix in the _users database and instead wrap
> >> CouchDB in your own permissions management.
> >>
> >> Stefan
> >>> On 22 Sep 2017, at 17:36, max <maxima...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm trying CouchDB 2.1 and facing an (strange?) issue. I have given
> >>> admin access through "Permissions" to "user1" and every user with the
> >>> role "manager". This allowed these users to call view from _design in
> >>> _users database. But this is not enough to delete other users, to do
> >>> that user have to be a super CouchDB Admin. Is this the expected
> >>> behavior? I got "Only admins may delete other user docs" whereas he is
> >>> admin.
> >>>
> >>> This is my _users database permissions:
> >>>
> >>> {"error":"unauthorized","reason":"Authentication
> >>> required.","admins":{"names":["user1"],"roles":["manager"]}}
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Max.
> >>
> >>
>
>

Reply via email to