From user-return-22899-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Nov 21 19:09:31 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3B43FD207 for ; Wed, 21 Nov 2012 19:09:31 +0000 (UTC) Received: (qmail 57569 invoked by uid 500); 21 Nov 2012 19:09:29 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 57505 invoked by uid 500); 21 Nov 2012 19:09:29 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 57496 invoked by uid 99); 21 Nov 2012 19:09:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Nov 2012 19:09:29 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [128.18.84.132] (HELO brightmail-internal3.sri.com) (128.18.84.132) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Nov 2012 19:09:23 +0000 X-AuditID: 80125484-b7fae6d000005ce7-bc-50ad26ce7534 Received: from exchange-hub01.SRI.COM (exchange-hub01.SRI.COM [128.18.23.153]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by brightmail-internal3.sri.com (SRI Internal SMTP Gateway) with SMTP id 88.43.23783.EC62DA05; Wed, 21 Nov 2012 11:09:02 -0800 (PST) Received: from EXCHANGE-DB08.SRI.COM ([fe80::a11e:7c21:6886:9a20]) by exchange-hub01.SRI.COM ([2002:8012:1799::8012:1799]) with mapi id 14.02.0298.004; Wed, 21 Nov 2012 11:08:59 -0800 From: Jim Klo To: "" Subject: Re: immutable _id's Thread-Topic: immutable _id's Thread-Index: AQHNx4RuXF7OXtgo/Ei063l2dc/sOZf0VVEAgAAQ48yAAMH0gIAABj+A Date: Wed, 21 Nov 2012 19:08:59 +0000 Message-ID: <79BF03BD-00EF-4BF1-AF7E-349E23CF7D24@sri.com> References: <2EC848E2-50CF-4F59-B677-6CDA737561D1@sri.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [107.202.69.108] Content-Type: multipart/signed; boundary="Apple-Mail=_2B42D8CD-FD59-47AE-977C-65925796D5C4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsXSICQ+U/ec2toAg1dHFSw69+xlc2D02Pjh OGMAYxSXTUpqTmZZapG+XQJXxse7B5gK5uVXzJz4m62B8VRKFyMnh4SAicS51fcZIWwxiQv3 1rN1MXJxCAnsZJJovjMBytnNKPH81TkWkCo2AXmJw9sfMIPYIgKWErcWfASLCwvISKy5vJoV Ii4r0TTzLnsXIweQ7Saxbgk3SJhFQFVixpNZbCA2r4CVxKwNJ1gg5v9klJjb+QoswSkQKDH3 9CcwmxHoou+n1jCB2MwC4hK3nsxngrhUROLhxdNsELaoxMvH/1ghbCWJW6tvs4IMZRaYwigx 49ABFohtghInZz5hmcAoMgvJrFnI6mYhqYMoSpLo+PGSGcLWlli28DWUbSDxtPMVK6a4vsSb d3OYIGxTiddHPzJC2NYSM34dZIOwFSWmdD9kX8DIvYpRJqkoMz2jJDcxM0cXFqPGesVFmXrJ +bmbGMFxG9Kyg3HFLsNDjAIcjEo8vJanVQKEWBPLiitzDzFKcDArifDueLgmQIg3JbGyKrUo P76oNCe1+BCjNAeLkjhvmDG/v5BAemJJanZqakFqEUyWiYNTqoGxYEn7qTYP5aSqXG2ZrRVe bz/x5R6eWOrNlc5ksG+L2zmdz0Wax378Oim3fWnNurC5H2YXayvecTxjVPvYmuF6zcIVqpqn yrofek1ceCI1/bBr616Li+W+e4xOWuyduP17YNeeoxdf1Xau+etbmvlx8+P0GTb5die/JXgp Gr1Pn9Qxq0e2P2qlEktxRqKhFnNRcSIAV7Q7stcCAAA= X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_2B42D8CD-FD59-47AE-977C-65925796D5C4 Content-Type: multipart/alternative; boundary="Apple-Mail=_E037CF9F-57FF-4FA4-898B-914288D6870B" --Apple-Mail=_E037CF9F-57FF-4FA4-898B-914288D6870B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ok, that's what I'm discovering. Well here's my thinking=85 I assuming I can use a VDU to forbid a = newDoc._delete =3D true and validate against a oldDoc.tombstone to = prevent reuse(I'm assuming that VDU get's executed regardless if the = delete is initiated via DELETE/POST verbs). Then use the update handler to manage construction of the tombstone doc. I think for our purposes I won't have to deal with the reverse proxy = (i've found that really tricky to work right anyways, i.e. inbound = DELETE is trivial, but delete via POST is tricky, because you can query = multi-keys using POST too=85 and some updates are okay in my case). As = long as the VDU will let me forbid newDoc._delete, I should be able to = not care about blocking access. Jim Klo Senior Software Engineer Center for Software Engineering SRI International t. @nsomnac On Nov 21, 2012, at 10:46 AM, Dave Cottlehuber wrote: > On 21 November 2012 16:12, Jim Klo wrote: >> Okay, say I did this. In the validate_doc_update, if someone tries to = delete a doc, would I be able to modify the new doc and remove the = _deleted field and just empty the doc myself - basically creating my own = tombstone? >>=20 >> - Jim >=20 > No, VDUs are a pass/throw result only, no modification allowed. You > might be able to fake this by sending your DELETEs to a custom update > handler, and some jigery pokery to prevent normal document DELETEs > being accepted within the VDU apart from via your update handler; not > sure if that's possible though so your fallback would be blocking > inbound DELETEs using a reverse proxy. >=20 > A+ > Dave --Apple-Mail=_E037CF9F-57FF-4FA4-898B-914288D6870B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ok, = that's what I'm discovering.

Well here's my thinking=85= I assuming I can use a VDU to forbid a newDoc._delete =3D true and = validate against a oldDoc.tombstone to prevent reuse(I'm assuming that = VDU get's executed regardless if the delete is initiated via DELETE/POST = verbs).
Then use the update handler to manage construction of = the tombstone doc.

I think for our purposes I = won't have to deal with the reverse proxy (i've found that really tricky = to work right anyways, i.e. inbound DELETE is trivial, but delete via = POST is tricky, because you can query multi-keys using POST too=85 and = some updates are okay in my case).   As long as the VDU will let me = forbid newDoc._delete, I should be able to not care about blocking = access.

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI = International
t. = @nsomnac

On Nov 21, 2012, at 10:46 AM, Dave Cottlehuber <dch@jsonified.com>
&nbs= p;wrote:

On 21 November 2012 16:12, Jim Klo <jim.klo@sri.com> = wrote:
Okay, say I did this. In the = validate_doc_update, if someone tries to delete a doc, would I be able = to modify the new doc and remove the _deleted field and just empty the = doc myself - basically creating my own tombstone?

- = Jim

No, VDUs are a pass/throw result only, no = modification allowed. You
might be able to fake this by sending your = DELETEs to a custom update
handler, and some jigery pokery to prevent = normal document DELETEs
being accepted within the VDU apart from via = your update handler; not
sure if that's possible though so your = fallback would be blocking
inbound DELETEs using a reverse = proxy.

A+
Dave

= --Apple-Mail=_E037CF9F-57FF-4FA4-898B-914288D6870B-- --Apple-Mail=_2B42D8CD-FD59-47AE-977C-65925796D5C4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCCBO0w ggRWoAMCAQICEBX3i1OyIZLyYjv7fwx/UYkwDQYJKoZIhvcNAQEFBQAwgdgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFTUkkgSW50ZXJuYXRpb25hbDEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDIxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QTEdMBsGA1UEAxMUU1JJIEludGVybmF0aW9uYWwgQ0EwHhcNMTIwMTAzMDAwMDAwWhcNMTMwMTAy MjM1OTU5WjCBwjEaMBgGA1UEChQRU1JJIEludGVybmF0aW9uYWwxKDAmBgNVBAsUH0luZm9ybWF0 aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9DUFMgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxEjAQBgNVBAMTCUphbWVzIEts bzEeMBwGCSqGSIb3DQEJARYPamltLmtsb0BzcmkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA2utx7vCP7eb6FitPXlP4Oo4fm2Bsx/lz7X7rHvqZRFdNkLtZjmppsofuWMRdrIMj xCW0lCQb2mvKwA/VSKvoyd4MBSIDYT/jVMz7OeCzNk0VhGKRwqXBlkvlirqhKOo4O24RU6C33c5p il3TDla/YwVbkFmKqGWNKnSddhUKpRVfQW3xJfbzjALWyx0OpLpxLmns6wrnKr6aYMWHOXZmCQ7J jwLWosKJgjlhLJOI+ZSK0JcrK7u2I9pIfYeVjJari4tPBbmoFV8S8vDFxWYryqvQuul7UVHO8VDC dP4jraUzOXZUIhzqmejClwmDsvvuNGsXpW+FaZJ7MwX8j3C5uQIDAQABo4IBRjCCAUIwCQYDVR0T BAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcXAjCBjjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcg VmVyaVNpZ24wCwYDVR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBmBgNVHR8EXzBdMFugWaBX hlVodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9TUklJbnRlcm5hdGlvbmFsSW5mb3JtYXRp b25UZWNobm9sb2d5U2VydmljZXMvTGF0ZXN0Q1JMMA0GCSqGSIb3DQEBBQUAA4GBAI7wVCjyQVMr YkTs+2zjKpjh9Oamq0rcbwyPAHQKJtz23JO0s/cVjsukw+lHvxaMSu8oCnsTa0NOc1a/n7PEoI7n e4j5XH3L6tUsEnNc+t237NoBrJP66my/2FSDpWkLGJ4sxioNEPonl0I0IuE8DiCP1JAdP8vJsXrE 2a5p2y8/MIIFCjCCBHOgAwIBAgIQFnwAoITZjkQu1m3KBG96NzANBgkqhkiG9w0BAQUFADCBwTEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAx OTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmswHhcNMDIwOTIzMDAwMDAwWhcNMTMxMjMxMjM1OTU5WjCB2DEL MAkGA1UEBhMCVVMxGjAYBgNVBAoTEVNSSSBJbnRlcm5hdGlvbmFsMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwMjEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMR0wGwYDVQQDExRTUkkgSW50ZXJuYXRpb25hbCBDQTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAzvnUwmuZmBSSAFVb0qoC0hhUL1a6f+AIHw5UpxW5oRTjsDtUzsCa+6Yg GvKUlisrnI/tPZFrupvHVNQjRj05fhHiABFinwlnCA7J80x3gZlBMwHrgoKYribJ1GTVmc1R0FmA B4KYzBeZjJZiNpqLEsEb0ORdzJYb2/UZazjL/fkCAwEAAaOCAegwggHkMBIGA1UdEwEB/wQIMAYB Af8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24u Y29tL3BjYTItZzIuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwKAYDVR0RBCEw H6QdMBsxGTAXBgNVBAMTEFByaXZhdGVMYWJlbDItODIwHQYDVR0OBBYEFC1OfgnwbUVBEaxx2j87 9iZKf2RkMIHoBgNVHSMEgeAwgd2hgcekgcQwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBh dXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrghEAuS9g zIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFAAOBgQBocPsx9foGtLlCL8coGlfjYx8GhbDYbdQ3 8w0P/BIw4D49KhAocMcivLESZiV8YYYFFx+ozAPtg0j0knx+tcdeDvWmSefavP+aKlRhpAWk5Z+n c34jLXdw9/+6WveM/OQQbPbd8asD6BsLcFlRm68KZY8kk7SjlsP1S6rQBiCX8jGCBHswggR3AgEB MIHtMIHYMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRU1JJIEludGVybmF0aW9uYWwxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAyMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0ExHTAbBgNVBAMTFFNSSSBJbnRlcm5hdGlvbmFsIENBAhAV94tT siGS8mI7+38Mf1GJMAkGBSsOAwIaBQCgggJiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTEyMTE5MDkwMlowIwYJKoZIhvcNAQkEMRYEFNemzFe9nSW0NTyl87Q9 7kXm4KfRMIH+BgkrBgEEAYI3EAQxgfAwge0wgdgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFTUkkg SW50ZXJuYXRpb25hbDEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDIxMDAuBgNV BAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEdMBsGA1UEAxMUU1JJ IEludGVybmF0aW9uYWwgQ0ECEBX3i1OyIZLyYjv7fwx/UYkwggEABgsqhkiG9w0BCRACCzGB8KCB 7TCB2DELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEVNSSSBJbnRlcm5hdGlvbmFsMR8wHQYDVQQLExZW ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMjEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyIENBMR0wGwYDVQQDExRTUkkgSW50ZXJuYXRpb25hbCBDQQIQFfeLU7Ih kvJiO/t/DH9RiTANBgkqhkiG9w0BAQEFAASCAQAP83QnH1P7JTPnFNsEFnVPSgFsvLn5lfM3K78q lHUFHpfQEX/AM/c01RJnwkfc6oLNWW/RDFfDQ4EJKcY1jC2a4nBXbY/ywl/eDEHz5+CIQbXdqRZk cVypSd2t+2rG3BKbAztNID4503VyAcU5/1vchse1OdIqNFgutnsUvGJHeICDbigT5TpK4C9SSyDg PUvXdsNFotp4OJEakCmrEyAPkO1Dh1nscfuDafQhe14l6ofyDFSQ+1o/aeLYutiFu9IOjrEURWQf Jv2E18e5fwA12MTRGyA+hqhsxtVpmFryRG2gUm/1qjaUbgKqvob6aI5eGqLqJp5/b8SXl2cppcnD AAAAAAAA --Apple-Mail=_2B42D8CD-FD59-47AE-977C-65925796D5C4--