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
