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 (http://couchdb.apache.org/docs/overview.html), 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>>> >>> >> >
