couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Shumaker <>
Subject Re: how to do http request within server-side _show or _view functions?
Date Tue, 12 May 2009 08:13:55 GMT
Here's what we do:

All of our writes go through our backend (the clients don't directly
talk to couchdb).
Whenever we're writing, we fetch the user's permissions object out of
the db (typically, it's actually available in the client-side cookies
in an encrypted fashion, so we save the fetch).   Ideally, the
validate_doc_update would allow you to check incoming HTTP headers as
well - in case you don't want to use CouchDB's built in user
authentication, but still want your own validation to run.   That's
not currently the case, so instead we stick a copy of the user's
permission object into the object we're about to write to couch, and
then write it.  Then the validate_doc_update has access to the
permissions as a member of the object that is being written.

Not ideal, but it works.  I'd love for validate_doc_update to take
HTTP headers - especially an additional JSON parameter, like a custom

On Thu, Apr 23, 2009 at 1:10 PM, Samuel Wan <> wrote:
> Thanks Robert. I realized I jumped too far ahead and I'm asking the
> wrong question. At what point should a developer write middleware for
> authentication and authorization instead of relying on CouchDB's
> facilities?
> Authentication:
> If authentication is enabled on CouchDB, the user submits
> username/password at the basic auth prompt. These credentials go to
> the authentication_handler specified by the default.ini file. If you
> store credentials as CouchDB documents, could you theoretically use
> the null_authentication_handler to allow all requests, and then use
> validate_doc_update to authenticate the userCtx object against
> credential documents in the database? Is this not possible because
> HTTP requests aren't supported on the server?
> Authorization:
> If you store permissions as CouchDB documents, how would you use
> validate_doc_update to compare userCtx or newDoc against the stored
> permissions document?  The validate_doc_update function cannot make a
> separate HTTP request to retrieve another permissions document stored
> in CouchDB.
> I'm basing these questions on the technical overview page
> (, which says: "A basic
> “author only” update document model is trivial to implement, where
> document updates are validated to check if the user is listed in an
> “author” field in the existing document. More dynamic models are also
> possible, like checking a separate user account profile for permission
> settings."
> The security_validation.js test will check an "author" document
> property for authorization, but the test seems to presume that the
> user has already been authenticated because the validate_doc_update
> function expects a userCtx object. The tests don't hint at how more
> dynamic models are possible.
> Any hints would be greatly appreciated.
> -Sam
> On Thu, Apr 23, 2009 at 10:14 AM, Robert Newson <> wrote:
>> I think the same rule applies, you should use the parameters supplied,
>> and only those, to implement your validate function.
>> You have the old document, the new document and the user context
>> object to play with, it sounds like that's enough for your case
>> anyway?
>> B.
>> On Thu, Apr 23, 2009 at 5:59 PM, Samuel Wan <> wrote:
>>> Thanks. What about validate_doc_update? My goal was to check a hashed
>>> key in the document submitted by a user by comparing the key with a
>>> stored document when the validate_doc_update is called.
>>> -Sam
>>> On Thu, Apr 23, 2009 at 9:33 AM, Robert Newson <>
>>>> I was just reading this (at
>>>> "Show and list functions are side effect free and idempotent. *They
>>>> can not make additional HTTP requests against CouchDB*. Their purpose
>>>> is to render JSON documents in other formats."
>>>> So they can't, and it's intentional.
>>>> B.
>>>> On Thu, Apr 23, 2009 at 4:38 PM, Samuel Wan <> wrote:
>>>>> Is there a way to do an http request within the server-side _show or
>>>>> _view functions, or is the JS context limited to what's defined by
>>>>> Spidermonkey and main.js? My understanding is that Spidermonkey
>>>>> doesn't provide an xmlhttprequest object.
>>>>> Also, does CouchDB ship with an interactive javascript shell, or do
>>>>> you have to build and install your own? I found the couchjs
>>>>> executable, but it only interprets javascript files.
>>>>> -Sam

View raw message