couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: The _security object should be versioned
Date Sat, 27 Aug 2011 05:32:12 GMT
On Fri, Aug 26, 2011 at 10:01 PM, Jason Smith <jhs@iriscouch.com> wrote:
> On Sat, Aug 27, 2011 at 9:09 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>>> The issue here is that adding a revision tree most likely means a
>>> requirement that the HTTP API changes to use MVCC tokens.
>>
>> _local docs already do. They just don't support ?new_edits, or
>> revs_info/revs/open_revs/meta, though I'd have to check.. It's not a hard
>> requirement that we support this stuff. And certainly the old /_security
>> endpoint could completely paper over this if we just make it clobber (which
>> no one on vanilla couch should care about).
>
> I propose there is no more /_security HTTP endpoint.
>
> Instead, _local docs get full MVCC support. You can post conflicts
> with ?new_edits=false and resolve them normally. The API becomes
> smaller and also more consistent.
>
> Next, _local/security is special to CouchDB. Upon an update, the
> current winning revision is cached in the DB header. This allows couch
> to quickly confirm read or admin permission when using the DB, and
> send secObj to validate_doc_update.
>
> Does this sound reasonable? I see two bonuses:
>
> 1. Full MVCC for _local would be nice for users, who are using _local
> more. If it's worth storing, it's worth storing in MVCC.
> 2. Design docs can validate the security policy.
>
> I can think of two issues:
>
> 1. Does this require updating the replicator to update _local docs correctly?
> 2. Only admins can change _security. But anybody with read access can
> change _local/*. Does couch special-case _local/security?
>
> --
> Iris Couch
>

1. You assume users using _local want conflicts there. In node local
data I don't see the benefit. Revision merging is for merging
revisions when writes happen in different order on different nodes.
Introducing revisions into something that should never have conflicts
seems... unproductive.

2. Now we're introducing super special consideration into specific doc
ids. Do not want.

I'm not the biggest fan of the current _security API. I'm also not a
fan of "Everything is a database!" I didn't like _users as a database.
I was quite irritable about _replicator as a database.  I'm fine
reusing code internally, but promoting these internals to database
level introduces some questions I've never seen answered. Putting
_security into this same level scares the bejezzus out of me.

Mime
View raw message