On Mon, Jan 18, 2010 at 12:52 PM, Brian Candler <[email protected]> wrote: > On Mon, Jan 18, 2010 at 10:11:47AM -0800, Chris Anderson wrote: >> The reader ACLs are just a clone of the db-admin lists we've had for a >> long time. The goal is to do the simplest thing that could possibly >> work. > > I disagree that it's the simplest thing that can work. IMO the simplest > thing would be to use regular docs, since all the infrastructure already > exists for those. > > Can you explain why you appear to have discounted this option? > > How about this for something really, really simple, > > 1. couchdb tests for the existence of a document with ID > "org.apache.couchdb.user:<username>" > or "org.apache.couchdb.role:<role>" [optional] >
The nice thing about the current comparisons is that they are made in-memory, with no db access necessary to perform them. This means I don't need to open a separate (_admin) connection to the database, load N documents, all before I get to the point where I still have to do the logic that I do now (comparing names and roles). > 2. if this document is present, the user has read access. If it is not > present, the user has no access. > > 3. That's it, for now. (*) > I like that you're keeping it simple. My big reason for just cloning the existing db-admins data structure and method is that we know it's solid, as it's been in Couch for a long time. Also, it fits the bill for what we need handled (as long as you have less than a few thousand groups in a database). > These documents scale. These documents can be queried via views. These > documents can replicate. We can control how these documents are added and > removed by leveraging the existing update mechanism (validate_doc_update). > Documents are great for application level functionality. But when we are talking about db-prefs (admins and readers) it makes things more predictable that they don't replicate. The security object will close the gap, here. It's just a document that's created by any applications that need it, expressing role mappings within the database. This would come in handy for say, customizing an inventory system for an auto-parts store. We should start a new thread about the security document. Again, the only way to scale this design to large #s of user accounts, is to keep the user accounts in the per-server users db, and control access via groups of users. There's a worst case where a user wants to have a "private" db with a large number of distinct readers. If that's your common case you might want to think about architecting around filtered replication instead. > These documents could also store user prefs for the database instance. > These documents could also hold the 'security context' for > validate_doc_update as well. > > So why not? > >> As far as I can tell, the only case these reader ACLs + the planned >> security document can't handle gracefully is the case where the >> security document starts to get too large (in which case you can >> probably shrink it again by creating a new server-level role.) > > No, that doesn't scale. Someone writes what turns out to be the next > Facebook and deploys it as db1 on your server. It manages its own roles > (i.e. users can sign up and it adds them as _readers to the database > itself). However if the _readers object becomes too big, you're saying > you'd have to grant a *server* level role of "facebook-user" to each user; > at this point, all new signups would have to be done by a process with > server-level privileges, which will be a real pain to implement. > The current design should gracefully handle a Facebook scale explosion of popularity and user accounts. You'd end up with a large users database. If a group of users wants to create a private workspace, they can create a new database to contain it, granting read access to a list of names. If the group of users becomes too big to list on the security object, they'll need to grant access instead to a global role that they all share. (moderated group membership is it's own problem but not insoluble.) serious couchapps will likely have a lot of asynchronous processes that run outside of couchdb. the results of these processes will be distributed via replication so eg a photo app could have a "central" host that does things like resize photo thumbnails asynchronously, replicating the new attachments back to the user. having useful async processes is a value-add sites can offer. > I just don't buy this. I think your proposal is really not all that different from what I've written. The difference isn't in the programming model (access granted to usernames and roles) supplied, it's in the implementation. What this means is that your proposal should be cleanly pluggable into the reader-acl system, and apps written for it should continue to run just fine. So if you want to start working on an industrial strength doc-store ACL model, perhaps someone will need it. I'm gambling that less functionality and a simpler interface will be worth it in terms of uptake. Chris > > Regards, > > Brian. > > (*) Personally I'd also like to see 'roles' in these docs, and the roles > here merged with the system level roles. So in the _users db you could > grant a "_reader" role which would allow someone to read all dbs in the > system - useful for server-level first-line support. But you can also grant > "_reader" within the database itself. But that's taking it further than we > need to get the basic functionality we're talking about. > -- Chris Anderson http://jchrisa.net http://couch.io
