[
https://issues.apache.org/jira/browse/COUCHDB-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799506#action_12799506
]
Alexander Trauzzi commented on COUCHDB-615:
-------------------------------------------
The first part of this note is an aside which could be separated out into
another discussion or issue if desired...
It's important not to conflate the functionality of reading the DB from an
application point of view (JSON request coming from a browser) and reading the
DB as a function of infrastructure (a scheduled replication).
I should note that I see the use in allowing replications to happen in the
context of a user per database, but *not per server*. This allows for local
copies of DB for higher availability, but they are only populated with data the
user can see.
Ultimately, replications and DBs will have to function in different contexts.
Control over what replications a server performs is still a system-wide
administrative task to be done with absolute authority.
Example:
1. http://www.giantsocialcdcollectionsite.net is running couchdb.
2. I make a user there.
3. I start to populate my CD collection and share information with others.\
4. I'm going on a plane and want my CD collection list with me.
5. I install CouchDB on my favorite OS via my favorite means.
6. As I am an administrator on my laptop, I elect to replicate
http://www.giantsocialcdcollectionsite.net.
7. http://www.giantsocialcdcollectionsite.net requires that I authenticate so
that it can filter my replication.
I think you can see how incredibly neat that ends up being...Of course then
some people will want ways to obfuscate the _design docs... But that's getting
into the nitty gritties.
Replication should function with indifference towards the DBs, users and
CouchApps being replicated and have little to nothing to do with them. It
should function behind the scenes as part of a broader, more general systems
design.
That's why things like per-DB roles and users may be nessecary to prevent the
server and the databases from bleeding into each other.
To me, replication is not something my users should even have to know about.
You write one app and if you need to scale out, you simply set up replication.
-=-
Anyway...
This issue that I have made here is over the permissions of authenticated users
of the DB and what data they can and cannot read:
Right now, there is no way to secure a request to
http://mycouchdb/mydb/myprivatedata on CouchDB without involving cumbersome
workarounds. I am loathe to think of the impact on the project if this is not
addressed.
> Role, ACL and Ownership Checks
> ------------------------------
>
> Key: COUCHDB-615
> URL: https://issues.apache.org/jira/browse/COUCHDB-615
> Project: CouchDB
> Issue Type: New Feature
> Environment: Ubuntu 9.10 64bit
> Reporter: Alexander Trauzzi
>
> It would be nice if CouchDB had a comprehensive offering for varying levels
> of access to documents and databases.
> Here are some ideas:
> o User lists are stored in the database, per database.
> o Roles and role membership are stored in the database, per database.
> o ACLs are stored in the database, per database.
> o CouchDB can use ACLs to store and simplify permissions for internal
> functionality (manage the db, manage users, add roles, add users to roles,
> etc...)
> o CouchApps can take advantage of the ACLs to support login/logout and
> arbitrary business rules as needed.
> o A simple API can be made to conduct role, ACL and ownership checks.
> I suppose there is some theory and discussion behind determining whether
> users, roles or both are stored in ACL rules. Also, something worth
> discussing is whether the checks are automatically performed by couchdb, or
> if views are to be performing checks prior to emitting data. Or both...
> Building all this into CouchDB would mean that it has a mechanism for complex
> applications to be developed. Ones that mandate privacy and other visibility
> concerns.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
