Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <1250986773.1249269074795.JavaMail.jira@brutus>
Date: Sun, 2 Aug 2009 20:11:14 -0700 (PDT)
From: "Curt Arnold (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-441) Finally implement
 pre-write-doc-edit handlers.
In-Reply-To: <1046774029.1248883814797.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738178#action_12738178 ] 

Curt Arnold commented on COUCHDB-441:
-------------------------------------

I wasn't expecting a new API,  but a designable or configurable feature for the existing _bulk_docs and PUT request handlers.  If you were using this to ensure that all documents had the appropriate username, timestamp, requesting ip address of last modification,  you'd need to disable _bulk_docs and the  PUT docid and rewrite all apps to use this new API.

A doc-edit-handler in the existing API would probably still be called on replication, but could distinguish between a replication action and a normal action.

As for the multiple doc-edit-handler, I think you could accept multiple handlers, but explicitly declare that there is no promised ordering.  If a designer adds doc-edit-handlers that conflict or have an order-dependency, then they have nobody to blame except themselves.


> Finally implement pre-write-doc-edit handlers.
> ----------------------------------------------
>
>                 Key: COUCHDB-441
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-441
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: HTTP Interface
>    Affects Versions: 0.10
>            Reporter: Curt Arnold
>             Fix For: 0.10
>
>         Attachments: COUCHDB-441.patch
>
>
> It would be useful for auditing to have the identity of the user who inserted a new revision and the timestamp of the operation to be inserted in the document in the same way that the new revision number is.
> Doing this at the application level is not adequate since it would be readily spoofable and would bypass the authentication handler.
> There is a comment in couch_db:update_docs about generating new revision ids, but I couldn't quite comprehend what specific code was responsible for inserting the id into the document.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.