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