On Sep 13, 2010, at 6:23 PM, Simon Metson wrote: > Hi James. > I think the thing to do is require that a document has a user field, > and that the value of that field matches the userCtx in the > validate_doc_update function. This then pushes the issue client side, and > makes the servers life easier. It could also be added by the front end apache > in the case of our deployment, I think. I can see this sort of trigger thing > being a good way of giving people a loaded gun aimed at their foot, they > certainly are in Oracle if you're not careful. > Cheers > Simon
The big issue is that any code which runs on normal document updates, will also run during replication, as replication is just a normal client. So this means that adding a field will happen not just on the original client PUT but also when replication happens. This is why _update is a separate handler. Chris > > On 9 Sep 2010, at 05:19, James Jackson wrote: > >> Hi all, >> >> Moving this from the users forum, as it appears what I'm after isn't >> currently available. For the security model I with to implement in a >> production CouchDB cluster, I would like to be able to force a field to be >> written to all docs based on the user context. The _update functionality is >> not what I am after as it requires the user to actually call it when writing >> a document (means security could be got-around by not calling this, and >> setting the required field in the passed document to something arbitrary, >> which would then not get caught by a validation function), and can't modify >> a document which is passed to it (as far as I can tell it can only modify >> existing documents, or create new ones). >> >> I see this ticket: >> >> https://issues.apache.org/jira/browse/COUCHDB-441 >> >> which talks about the functionality I am after, but appears to have morphed >> into what is now there. >> >> I am willing to implement such functionality, if it already doesn't exist, >> but wonder if this would be welcome in the trunk, or if there are killer >> pitfalls which stop this being possible. I note that in the discussion on >> that ticket there is talk of how to deal with multiple such modify-on-write >> functions, perhaps this is one area that needs discussion? >> >> In any case, I'll probably implement this for our CouchDB installation, but >> it would be good to make it generic and globally useful such that I can >> contribute it back. I know of a number of people who would like this >> functionality... >> >> Regards, >> James. >
