You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Mario Scheliga <ma...@sourcegarden.de> on 2010/02/19 10:38:52 UTC
Accessing Views - Security
Hi Everyone,
i am just thinking about some security issues with couchdb. I just
want to adjust the access to
stored Data like in ACLs and how would you do this if couchdb runs on
different clients. Thinking
about a Groupware Project with clientside-persistence.
1. encrypt/decrypt fields in couchdb-docs? (with certificates or
something like that
2. on a server i could hide some urlparts by using a proxy, so the
user have to use my show,list,_update functions, where i can implement
my acl logic, but how is this done one a client site environment,
where the user has full-access to the couchdb-instance
how is that done right?
greetz
mario
--
Sourcegarden GmbH HR: B-104357
Steuernummer: 37/167/21214 USt-ID: DE814784953
Geschaeftsfuehrer: Mario Scheliga, Rene Otto
Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
Schoenhauser Allee 51, 10437 Berlin
Re: Accessing Views - Security
Posted by Mario Scheliga <ma...@sourcegarden.de>.
Hi Chris,
that sounds great. What do you mean with "via a validate_doc_update
function". Sounds to me like
an Pull-Replication, where the clients seems to decide what to pull? i
think i didn't get this point, right? :-)
greetz
mario
Am 19.02.2010 um 14:43 schrieb J Chris Anderson:
>
> On Feb 19, 2010, at 4:38 AM, Mario Scheliga wrote:
>
>> Hi Everyone,
>> i am just thinking about some security issues with couchdb. I just
>> want to adjust the access to
>> stored Data like in ACLs and how would you do this if couchdb runs
>> on different clients. Thinking
>> about a Groupware Project with clientside-persistence.
>>
>> 1. encrypt/decrypt fields in couchdb-docs? (with certificates or
>> something like that
>> 2. on a server i could hide some urlparts by using a proxy, so the
>> user have to use my show,list,_update functions, where i can
>> implement my acl logic, but how is this done one a client site
>> environment, where the user has full-access to the couchdb-instance
>>
>> how is that done right?
>>
>
> This is best done via filtered replication. (There are some new
> tools coming that will make this easier, too.)
>
> On your server you can keep one database per client, and control
> which documents are allowed to replicate to that database (via a
> validate_doc_update function). Then the client can replicate that
> entire database and do whatever they want to it at home, but you
> know they only have data they are allowed to see.
>
>> greetz
>> mario
>>
>>
>> --
>> Sourcegarden GmbH HR: B-104357
>> Steuernummer: 37/167/21214 USt-ID: DE814784953
>> Geschaeftsfuehrer: Mario Scheliga, Rene Otto
>> Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
>> Schoenhauser Allee 51, 10437 Berlin
>>
>
--
Sourcegarden GmbH HR: B-104357
Steuernummer: 37/167/21214 USt-ID: DE814784953
Geschaeftsfuehrer: Mario Scheliga, Rene Otto
Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
Schoenhauser Allee 51, 10437 Berlin
Re: Accessing Views - Security
Posted by J Chris Anderson <jc...@couch.io>.
On Feb 19, 2010, at 4:38 AM, Mario Scheliga wrote:
> Hi Everyone,
> i am just thinking about some security issues with couchdb. I just want to adjust the access to
> stored Data like in ACLs and how would you do this if couchdb runs on different clients. Thinking
> about a Groupware Project with clientside-persistence.
>
> 1. encrypt/decrypt fields in couchdb-docs? (with certificates or something like that
> 2. on a server i could hide some urlparts by using a proxy, so the user have to use my show,list,_update functions, where i can implement my acl logic, but how is this done one a client site environment, where the user has full-access to the couchdb-instance
>
> how is that done right?
>
This is best done via filtered replication. (There are some new tools coming that will make this easier, too.)
On your server you can keep one database per client, and control which documents are allowed to replicate to that database (via a validate_doc_update function). Then the client can replicate that entire database and do whatever they want to it at home, but you know they only have data they are allowed to see.
> greetz
> mario
>
>
> --
> Sourcegarden GmbH HR: B-104357
> Steuernummer: 37/167/21214 USt-ID: DE814784953
> Geschaeftsfuehrer: Mario Scheliga, Rene Otto
> Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
> Schoenhauser Allee 51, 10437 Berlin
>