> On Feb 27, 2019, at 3:47 PM, Michael Fair wrote:
>
>>
>>
>>> This might be what is already planned (it hasn't sounded like it to me
>>> though).
>>> And I definitely think changing the perspective to make "databases" a
>>> function of the access control system and to make views based on
Based on discussion with Russell Branca (chewbranca) in IRC, we need to
abort this RC vote as he is effectively voting -1. Here's the full
transcript of our discussion:
16:06 <+Wohali> chewbranca: you there? are you seeing these eunit
context setup
Hi there,
As part of ASF's move of all Git repositories to GitHub, some of our
newer repos started having their notifications routed to the wrong
mailing list (dev@ instead of notifications@).
This should be fixed now, see https://issues.apache.org/jira/browse/INFRA-17917
Committers/PMC: When
>
>
> > This might be what is already planned (it hasn't sounded like it to me
> > though).
> > And I definitely think changing the perspective to make "databases" a
> > function of the access control system and to make views based on "access
> > controlled collection results" instead of
Not to pile on here but "Once you read your available docs into your DB, you
can grant yourself
write privileges to every document there." does seem to miss the mark.
All replication is doing is making a copy of data you have access to. You can
modify your own copy as you please, it doesn't
> On Feb 27, 2019, at 3:01 PM, Michael Fair wrote:
>
> On Wed, Feb 27, 2019 at 10:36 AM Adam Kocoloski wrote:
>
>> Hi Mike, just picking out this one snippet:
>>
>>> On Feb 27, 2019, at 12:16 PM, Michael Fair
>> wrote:
>>>
>>> If I get a replica of a database from your server, what, if
>
> There are certainly a bunch of interesting challenges around providing
> identities that are meaningful across multiple servers in different
> domains, and I think that’s worth digging into, but I wanted to avoid
> anyone thinking that replication could trivially defeat the per-doc _access
>
On Wed, Feb 27, 2019 at 10:36 AM Adam Kocoloski wrote:
> Hi Mike, just picking out this one snippet:
>
> > On Feb 27, 2019, at 12:16 PM, Michael Fair
> wrote:
> >
> > If I get a replica of a database from your server, what, if anything,
> > prevents me from granting myself access controls to
Hi Mike, just picking out this one snippet:
> On Feb 27, 2019, at 12:16 PM, Michael Fair wrote:
>
> If I get a replica of a database from your server, what, if anything,
> prevents me from granting myself access controls to the entire database?
Replication is a client of the API like everyone
>
> 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.
>
Then I think we're saying the same thing except I'm
> The application would override the _all_docs and _changes endpoints, and if
> a user has enabled access=true for that database then you could then return
> the _all_docs and _changes requests from your application. The epi http
> work is pretty fancy I think we could do some cool things around
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
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 wrote:
>
> > On Feb
13 matches
Mail list logo
