That sounds along the lines of what I was thinking. You're right, show functions are needed, too, so you can still pull a user's profile from the _users table, but have the show function return everything but their hashed password and salt.
On Mon, May 3, 2010 at 3:47 AM, Jan Lehnardt <[email protected]> wrote: > May back-of-the-head solution for this scenario is to introduce "blessing" of > update functions so they are invoked on regular API calls. Same for show > functions. > > I obviously haven't thought this through :) > > Cheers > Jan > -- > > > On 2 May 2010, at 18:06, Paul Bonser <[email protected]> wrote: > >> Sorry for the wall of text there, but I had lots of thoughts to get out. >> >> Another good use of the ability to allow update handlers but reject >> direct POSTing of documents, would be to allow users to register new >> accounts, but not allow them general access to the _users DB. As it >> stands right now it's a huge security hole that anybody can read from >> the _users db, including the salt and hashed password of any user. >> >> On Fri, Apr 30, 2010 at 1:13 PM, Paul Bonser <[email protected]> wrote: >>> Hey everyone, >>> >>> I've been looking at update handlers, and I see a real opportunity to >>> simplify application development and more easily secure an application >>> which allows users to communicate directly with CouchDB. >>> >>> Imagine this scenario: >>> >>> I'm building a couchapp which allows users to play board games against >>> one another. There are only a fairly small number of things involving >>> a change to the DB that a player can do: >>> >>> - Start a new game >>> - Make a move on an existing game >>> - Forfeit a game >>> >>> So, instead of teaching the client code all about the format of the >>> document, and then in a validate_doc_update function checking every >>> field to make sure the user didn't do anything they shouldn't have, I >>> simply make an update handler for each of these possibilities, and the >>> user only gives the minimum required input "This is the game I'm >>> referring to, move my piece from a5 to c7." The update handler just >>> has to check if that's a valid move, and it knows that none of the >>> fields have been modified. >>> >>> The problem is, if a user can make a call to an update handler, they >>> can also POST directly to a document, so I still need to have a >>> validate_doc_update function, and since they could potentially still >>> POST directly, I *still* have to check every field to make sure they >>> didn't do anything they shouldn't have. >>> >>> Basically, what I need is some way of being able to check, within a >>> validate_doc_update function, what means the user used to update the >>> document, and then all I'd have to do is check if the update came via >>> a update handler, and I'll know the changes are safe (assuming I wrote >>> my update handler safely). >>> >>> So my question now is: what is the best way to add the ability to >>> check the source of a document update? >>> >>> My first thought would be to insert an attribute into the (as yet >>> undocumented) fourth argument to validate_doc_update functions, >>> indicating where the request came from. That could either be the path >>> of the request, or perhaps a string indicating what request type it >>> was. The only problem with this approach is that it doesn't carry over >>> into replication very well. >>> >>> My second idea would be to allow update handlers to indicate in their >>> response that the document update should happen under the identity of >>> a different user. That way, an update handler just sets the updating >>> user to be some user that has admin access to the current database, >>> and the validate_doc_update function just has to check that the >>> updating user has the admin role. >>> >>> Any thoughts or comments? If either of those ideas sounds reasonable, >>> I'd gladly offer to write the patch to add the new functionality >>> myself. >>> >>> -- >>> Paul Bonser >>> http://probablyprogramming.com >>> >> >> >> >> -- >> Paul Bonser >> http://probablyprogramming.com > -- Paul Bonser http://probablyprogramming.com
