Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of misterpib@gmail.com designates
 209.85.211.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=lndaHdmRNm8AYKr59mCUY6cSaHrRTI92YrLT0H09N5cgldvssb3XG80JRXbDK4uoY4
         eI1OZINZOVf9V9BqlNiJCg7E+B9uORoyYqjK3zq9TSOLT+8OK9mn7cv2rUAiQd+MxJl7
         NLYtXCbY9WPuG8uvV/Ik5VdVkDsMfOKyuv6hA=
MIME-Version: 1.0
From: Paul Bonser <misterpib@gmail.com>
Date: Fri, 30 Apr 2010 13:13:26 -0500
Message-ID: <v2he6101e101004301113qa162fca3kf9abd2db3c5df7e3@mail.gmail.com>
Subject: Update Handlers as a safe entry point
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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