couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Initial couchdb accounts feedback
Date Mon, 11 Jan 2010 13:10:51 GMT
On Sun, Jan 10, 2010 at 07:05:59PM +0000, Brian Candler wrote:  
> I could of course frig the roles to include the db instance name, e.g.
>    "roles": ["db1:owner", "db2:read"]
> but:
> 
> (3) The 'owner' of a database needs to be able to grant access to other
> users. So bob@example.com, who has role db1:owner, needs to be able to
> grant
> or remove db1:<any> from any user on the system.
> 
> It would be fine if the roles were stored as document(s) within db1,
> because
> I could use validate_doc_update to allow anyone with the appropriate role
> to
> update them.
> 
> As couchdb is now, where the roles are stored within the global user[s]
> database, they can only be managed by a couchdb server administrator.

Actually, it looks like I should be able to replace _users/_design/_auth
with my own version, so I could implement a (systemwide) policy that role
'foo:admin' could add or remove role 'foo:bar' from any user.

The problem then becomes: within an application's validate_doc_update
function, how do I determine what database instance it is running within?
That is, a user might have role 'db1:bar' but I need to know whether I am
inside database db1 or not to decide whether they are authorized. I don't
think I can determine this from the parameters passed to
validate_doc_update.

Regards,

Brian.

Mime
View raw message