couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bonser <>
Subject Re: Update Handlers as a safe entry point
Date Mon, 03 May 2010 14:05:42 GMT
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 <> 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 <> 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 <> 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
>> --
>> Paul Bonser

Paul Bonser

View raw message