incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wout Mertens <wout.mert...@gmail.com>
Subject Re: Best performing login implementation?
Date Mon, 06 Sep 2010 17:21:11 GMT
If you store confidential information, they can be in 2 categories
1. data the user has to be able to read
2. data only you have to be able to read

So if it is category 1, simply add a database for that data (remember, many databases per
couchdb server) and add only the user to the readers.

If it is category 2, put all that confidential data in a database and add only your server
user to the readers.

If it's a mix, implement 2 and expose some of the info through your server scripts for the
user to use. I wonder if you can use the CouchDB authentication in that case though :-/

Wout.

On Sep 6, 2010, at 19:15 , Tiago Freire wrote:

> 'Users can read the entire database' is a big no-no for our design. We store
> confidential information from our clients an they cannot see each others'
> stuff.
> Now, the 'everyone-can-read' model is all the CouchDB authentication system
> offers, or it is just a default, and I can restrict reading using the
> default authentication scheme?
> 
> 
> On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jchris@apache.org> wrote:
> 
>> 
>> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
>> 
>>> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
>>> 
>>>> Also it is worth noting that CouchDB has a builtin authentication system
>> that gets this right, and you might just be able to piggyback on it,
>> depending on your application:
>>>> 
>>>> 
>> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
>>> 
>>> So the security model is:
>>> - Admins can do everything on all local databases
>>> - Readers can read the entire database
>>> - Writes can have any model you like with validation functions
>>> 
>>> So if you want to segment your database readers you have to segment your
>> databases.
>>> 
>> 
>> Yes.
>> 
>>> Furthermore, if you would like to use LDAP authentication, you'd have to
>> use an LDAP-to-OAuth server.
>>> 
>> 
>> It should be a very simple patch to add new Erlang authentication handlers
>> for things like LDAP, Kerberos, etc. That might be simpler than adding a
>> bunch of glue to speak OAuth.
>> 
>>> Correct?
>>> 
>>> Wout.
>> 
>> 
> 
> 
> -- 
> -----
> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe


Mime
View raw message