On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau <[email protected]> wrote: > On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <[email protected]> wrote: >> Devs, >> >> I'm attempting to make more sense of CouchDB's authentication system. >> The current system is a proverbial ball of spaghetti. I'm still in the >> investigation stage of my work, and I'm writing this to clarify my >> thoughts and solicit feedback. >> >> To start with, the current default_authentication_handler is unaware >> of the users db. I plan to fix that, and to change default.ini so that >> cookie_auth is enabled for all Couches. I also plan to make it so that >> CouchDB never triggers the basic-auth popup box, because we all know >> that that's a UI dealbreaker. (We'll still accept basic auth, we just >> won't prompt for it.) > > Auth popup is created by the browser. Does it imply an ui would be > needed to connect to CouchDB via the browser ? Also how can we detect > the basic auth if you don't send the 401 status with WWW-Authenticate > ? I think we should keep the default behaviour (popup) but on the > other hand reusing the system used with cookie aut allowing us to not > popup by just providing another header.
I think it is possible to accept basic-auth when users provide it, without sending the sort of response that triggers the popup in the browser. If you have to have that popup to be RESTful, then I don't want to be RESTful. On a serious note, I can't imagine anyone ever writing a serious CouchApp if the browser-auth-popup is lurking there, ready to ruin the user experience at every turn. > >> >> One question is how to manage system roles such as _admin. My thinking >> is that the users db validation function will forbid roles starting >> with underscore from being stored on user's documents. Instead, when >> Couch loads a user from the db, it will cross-reference the user with >> the list of node and db admins, and apply the _admin role when >> appropriate. This way we can avoid having more than one distinct type >> of user in the system. This should also allow us to have more system >> roles (prefixed with underscore) in the future. > > Not sure to follow here.Do you plan to remove admins from ini ? I > would be to keep them. They are like super users. We could create > another class of users for that. Maybe _staff to follow unix > terminology? > I don't plan to remove admins from the config. The _admin role will be applied to users in the users db, based on the config setting. (Also, if you don't use the user's db, you will not notice any change at all.) Another _role that we could add in the future is a _replicate role, which normal users could have the option to run replication under. This would allow validations to enforce things like author names, without requiring users to run replication as _admin and expose design docs to potential unwanted changes. > >> >> I'm also thinking that the /_session handler should speak JSON >> primarily (but I'll probably leave in the ability to handle >> form-encoded request bodies as well). >> > We could just detect http headers and provide the needed response for > that. Keeping the form encoded would be good. It's already used in > some applications. I think we'll end up supporting both, but I want to get the JSON API in place and well tested. > >> As far as security on the users DB, I don't plan to change anything >> from how it is now. The basic idea is that anyone can create a new >> user document (eg anyone can signup), but only _admins can set roles >> on user documents. Additionally, only _admins or the user whos >> document it is can update a user document. >> >> In the future, when we implement reader access-control-lists for >> databases, they will be useful to further secure the users DB. For >> now, the users db will be world-readable, which is fine as long as >> no-one breaks the crypto. We're already using strong hashes and long >> salts, so I think we're already relatively secure. >> > Not really since salt is available and hash is only sha1. I think we > could make it harder but I agree with a strong encryption we don't > need to hide them. > > >> None of what I'm doing should change the oauth handlers. > > oauth is a problem here if it's in a public db. > I agree hiding the users db would be more secure, but the current codebase uses a public users db. I've got to draw the line for this patch somewhere. Should we eventually get per-db reader ACLs, they'll be perfect for making this a little more secure. > >> >> Thanks for your attention. Please fire aware with questions and comments. >> >> Happy holidays, >> Chris >> > Thanks you too. I would be happy to help on this part I have a project > that just wait for a some auth. So tell me if I can help. > > - benoît > The code I've written so far is a huge mess, so there's not much room to help at the moment. I'll hopefully have it in a publishable state in the next few days. (yay to holidays, the one time I can actually get work done!) One problem I've run into is how to enforce that logins are unique within the users db. The simple answer is to make the username into the docid. This has the upside that if 2 sites are replicated together, any duplicated user docs will go into a conflict state immediately. I think this is better than having the ambiguity come up at login time, when it's not clear which user document to test the password against. If we do login-as-docid, then we can encourage people to use email addresses as login tokens, which should help avoid spurious conflicts when sites are merged. The other option is to keep doing what we do now, and run a view query to see if the user name has been taken before saving the document. This has the advantage of mostly working while avoiding replication conflicts. However, as I said above, I think we want those replication conflicts. Also, having a uniqueness constraint on a field other than _id is one of those things that seems like it works, until it doesn't work. Then when it doesn't work (b/c of distributed apps or race conditions) the whole house of cards comes falling down. So I think I'm gonna switch to docids like "user:[email protected]" and "user:Monty4eva". If this is a stupid idea please convince me not to do it. Cheers, Chris -- Chris Anderson http://jchrisa.net http://couch.io
