incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: Question regarding P2P authentication
Date Tue, 20 Apr 2010 19:26:10 GMT

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
> 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.


> If there is a better solution, what would that be?
> Best
> Daniel

View raw message