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 ב-13 בספט 2012, בשעה 17:13, Dave Cottlehuber <d...@jsonified.com> כתב/ה: > On 13 September 2012 08:17, svilen <a...@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
