Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of sshumaker@gmail.com
 designates 209.85.221.112 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=SGxYTeXe6aDwFSIOSUl1f5LpIMNhE2oXLUn5Ty0Mua7muwYNSOXHKQje6nOq36YrQI
         9sXmCQdFTFsToEFaIFBd9xLU3TOMHItCr6JMrwufRSZ5JV2GaG3SVihItKl/2wKWDsJM
         18bh56NZnWQAWbos5/x1tHEOfkwh3P0Q/xs1Q=
MIME-Version: 1.0
In-Reply-To: <1d3db2990904231310i4716a023sdcd4b5287a33e08@mail.gmail.com>
References: <1d3db2990904230838r34a4c060t5ae305e67145a285@mail.gmail.com>
	 <46aeb24f0904230933u1a9bad32r9dfdb073c768a11a@mail.gmail.com>
	 <1d3db2990904230959q24530cbat420cee8688f53490@mail.gmail.com>
	 <46aeb24f0904231014u6cc5adadx4900ffb43b66a819@mail.gmail.com>
	 <1d3db2990904231310i4716a023sdcd4b5287a33e08@mail.gmail.com>
Date: Tue, 12 May 2009 01:13:55 -0700
Message-ID: <261cf6280905120113i72595eb1m79333c3cb2a8c77@mail.gmail.com>
Subject: Re: how to do http request within server-side _show or _view
	functions?
From: Scott Shumaker <sshumaker@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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
userCtx.

On Thu, Apr 23, 2009 at 1:10 PM, Samuel Wan <sam@samuelwan.com> 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? =A0The 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
> (http://couchdb.apache.org/docs/overview.html), which says: "A basic
> =93author only=94 update document model is trivial to implement, where
> document updates are validated to check if the user is listed in an
> =93author=94 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 <robert.newson@gmail.com>=
 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 <sam@samuelwan.com> 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 <robert.newson@gmail.com=
> wrote:
>>>> I was just reading this (at
>>>> http://wiki.apache.org/couchdb/Formatting_with_Show_and_List);
>>>>
>>>> "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 <sam@samuelwan.com> 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
>>>>>
>>>>
>>>
>>
>