On Apr 20, 2010, at 11:43 AM, Daniel Truemper wrote: > Hi everyone, > > I have a question regarding P2P apps in CouchDB and the new authentication > method. > > The setup could be like that: a central server is the main synchronization > point. If the user logs in (via some kind of reverse proxy) she is > automatically redirected to her user DB on the server side. So, the central > CouchDB instance has a _users database with her user document. > > At the same time I want her to run CouchDB locally. I.e. she should have the > same user document on her local CouchDB instance so that the passwords are > the same. If she changes her user document locally I would like to update > this to the server database and vice versa. Could this be done via filtered > replication? >
you won't need a filter, as users are only allowed to update their own user doc. Even if a user defeats the validation locally, the central server will only allow replication to update the correct document. > If this works like I described it, there is only one open question: how can I > prevent the users from replicating all documents P2P, without the > synchronization server. I have the usecase where not every user is allowed to > see all documents, so I would have to prevent those documents from > replicating between two end users. I think this should be done via the > validate doc update function?! You can use filtered replication to keep a proxy database on the central server, one for each user, that the user can replicate freely to and from. Then you can use filters when replicating between the central db and the proxy db. A simpler option (depending on your app) would be to allow users to create workgroups, and each workgroup gets a db which members can replicate, read and write to. This is simpler than a central db plus it is easier for users to reason about. I think the model of a central db with complex policy controls for each document is a holdover from the relational days. It's much simpler to think of a database as a shared workspace, where anyone who has access has full access. Chris > > If there is a better solution, what would that be? > > Best > Daniel
