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
