couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svilen ...@svilendobrev.com>
Subject Re: use case: replication of many databases, with/by many users
Date Mon, 24 Sep 2012 04:00:21 GMT
i've been reading 
 http://wiki.apache.org/couchdb/Security_Features_Overview
 http://wiki.apache.org/couchdb/Replication
for a while, but some things inbetween them are missing. 

so after some trial-and-errors here's what i understand/assume so far:

* couchdb users are per server-instance, in separate /_users db
* an user can see/change only his /_users/id doc-profile (this
  also means s/he can add hirself to any known/guessed role. hence
  roles are not for guarding unauthorized use - but only for
  specialization)
* databases can have /db/_security.readers.names as list of
users allowed to read+write (or .admins for extra stuff)
** replication as plain http+read/write is under these permissions too
- so cant replicate databases if unauthorized in them
* only server-admins can create/delete a db
* only db-or-server-admins can change db/_security
* /db/_security is NOT replicated 
* /_users can be replicated manually

are these correct? especially the the /db/_security being
non-replicable ? i could not make it replicate. If that is the case,
then making *equal* copy of some database is not that
straightforward - one has to manualy query+copy the _security object.
repeat for each if there are many-many databases.

so, if the couchdb user-authentication is to be used @ server, any
create-db or add/del-user-to-db has to be made explicitly by some
server-side app, before being usable. Or, if made locally, e.g. because
no connection, (assuming u can do anything locally), they once there
is connection, and the local db/changes is published to server, these
have to be all re-played at server-side to actualy happen - i.e. create
db, replicate data, then re-play add/del-user @ server to rebuild the
db/_security.

or am i missing something?

ciao
svilen


On Tue, 18 Sep 2012 10:16:16 +0300
Ido Ran <ido.ran@gmail.com> wrote:

> This solution will make the hub node a single point of failure and
> further make it either unable to use peer-to-peer or by using p2p you
> go around the security model and there is no good way to denied p2p
> replication. 
> 
> I'm also looking into the use case of database per topic replicated
> to each device and back so I'll be glad to see sound security model
> too. 
> 
> Ido 
> 
> 
>  
> > On 13 September 2012 08:17, svilen <az@svilendobrev.com> wrote:
> >> g'day
> >> this is about per-user authentication of replication. (similar to
> >> the thread "App layer on top of replication" but that's not
> >> exactly my use-case).
> >> 
> >> imagine a chat-room. each message is a document. each chat room is
> >> a database. no conflicts. Each user can participate in many chat
> >> rooms (=databases) and have them replicated to and from localy,
> >> continuosly (on as many devices he wants).
> >> 
> >> the question is: how to make the authentication/security properly?
> >> 
> >> so far i'm guessing i should have a separate user-account
> >> layer/module to know who is who on server.
> >> 
> >> how to allow users to use only chat-rooms they're registered in?
> >> in case all couchdb-user's credential live in database, and hence
> >> are replicated, that is not usable..
> >> 
> >> how about replication itself? wrap it in some user-authenticated
> >> api-call/url-rewrite (and disable it for external world)? or
> >> something else?
> >> 
> >> ciao
> >> svil
> > 
> > Assuming you have a hub node that has all user accounts and a db per
> > chat room, that all external users replicate from/to, you could
> > simply use DB roles.
> > 
> > When you join a chat room, you'd need to be added to the role list
> > for that DB (by some process external to couch that knows if you are
> > allowed to access it), and then you could set up replication on the
> > endpoint node.
> > 
> > Would that be sufficient?
> > 
> > A+
> > Dave

Mime
View raw message