It’s possible, but I don’t see how to scale it efficiently.
If you let a user create a view and access it directly, you need to ensure that
the system which reads the documents only reads the ones that the user can
access. Effectively, the design doc needs to inherit the access roles of the
user who created it. An external application could enforce this although it
would somehow need to be a different syntax so the regular view system doesn’t
pick up the ddoc and build the view while reading all documents.
Assuming you take care of the above, the next challenge is a performance one.
If you have 100 users creating their own views off of the vanilla _changes feed
of a single database, the indexing process for each view is 100x more expensive
than it needs to be (because each indexer scans and discards 99% of the docs
due to _access restrictions). The in-database approach tries to address this by
creating a _changes feed where the entries are prefixed by the _access required
to read them, so an indexer can quickly skip the ranges that it knows are
inaccessible.
Adam
> On Feb 27, 2019, at 6:47 AM, Garren Smith <gar...@apache.org> wrote:
>
> Hi Adam,
>
> I probably didn’t give views the most thought. I was thinking we could
> implement views by either using the changes feed or a new query engine like
> we do for mango. Does that make sense or is it not really possible?
>
>
> On Wed, Feb 27, 2019 at 2:26 AM Adam Kocoloski <kocol...@apache.org> wrote:
>
>>
>>> On Feb 26, 2019, at 7:12 PM, Michael Fair <mich...@daclubhouse.net>
>> wrote:
>>>
>>> On Tue, Feb 26, 2019 at 3:38 PM Adam Kocoloski <kocol...@apache.org>
>> wrote:
>>>
>>>> Mike,
>>>>
>>>> If I’m reading you correctly you’re concerned about cross-domain
>>>> authentication. A good problem and worth discussing, but I think it’s
>>>> cleanly decoupled from the per-doc access control work, which is
>> focused on
>>>> *authorization*.
>>>>
>>>>
>>>
>>> I don't think I'm talking about the same cross domain authentication you
>>> are talking about. I think you are talking about a web page from Domain
>>> (B) attempting to access Couch resource in domain (A) (Cross site
>> scripting
>>> access). That's not what I'm talking about.
>>>
>>> I'm talking about what ought to happen with the authorization control
>>> definitions when you have two Couch servers, one running in Domain (A)
>> and
>>> one running in Domain (B) with different sets of system users, such that
>>> the authorized entities in the bidirectionally replicated database don't
>>> exist in both server instances (the two distinct domains share the same
>>> document database but have disparate sets of authenticated system users).
>>>
>>> In other words the ("sam", "pete", and "joe") users on domain/machine A
>> are
>>> not the same thing as the ("mary", "betty", and "sue") users on
>>> domain/machine B; yet the replicated database between the two machines
>> has
>>> the same access control document authorization descriptors in both
>> places.
>>
>>
>> Thanks Mike, I did understand you correctly the first time. I still
>> maintain that’s in the realm of authentication, not authorization, and
>> should be cleanly separable from the problem of implementing per-document
>> access controls. Cheers,
>>
>> Adam
