> On Feb 27, 2019, at 3:01 PM, Michael Fair <mich...@daclubhouse.net> wrote: > > On Wed, Feb 27, 2019 at 10:36 AM Adam Kocoloski <kocol...@apache.org> wrote: > >> Hi Mike, just picking out this one snippet: >> >>> On Feb 27, 2019, at 12:16 PM, Michael Fair <mich...@daclubhouse.net> >> 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 else and cannot bypass >> the access controls on the source. You can only create a replication which >> has at most access to all the documents in the database that you can access >> yourself; i.e. a replication of a database with per-doc access controls >> enabled may only transfer a subset of the documents in the database. >> > > Right, but generally speaking READ access is very prevalent, WRITE access > is much more restrictive. > > Or are these "access controls" really just the binary "exposed"/"not > exposed" sort such that had these documents simply gone into a different > database in the first place, and the view indexes tracked in a "per > database" way then everything would work as expected? > > In fact, maybe "the same doc in multiple user centered databases" is not > such a bad idea/model to consider. > > Currently, I see this idea in Couch that documents belong to a particular > "named document collection" called a database. A view is really just > another kind of "named document collection". > > What if instead of a "database", there was simply the single universal > document store and a "database" is then more like a "view" that documents > became a member of just like a user's access controlled "slice" would be? > (i.e. the dbname becomes more like of a document access filter and less a > grouping and storage boundary) > > Users then have a "per user scope/database" which they always access > through when they connect to the server. > The top level list of "_databases" the user sees is actually just a list of > those "named collections" that the user can access. To the client side > APIs nothing really changes for them, what changes is how Couch internally > organizes itself to make "databases" a construct of the access control > feature and no longer a structural primitive. > > Documents now carry the information about what "named collections" they > belong to in the same way as what entities are authorized to access them, > and "databases" basically become a "view" grouping by the "_collections" > array field member values on each document. > > > Many people have requested the option to expose the same document to > multiple databases and then use database access rights to enforce per user > access and share documents between users. I've even wanted this feature > from time to time. If views have to be modified to hide unauthorized > documents anyway, this seems a perfect opportunity to address this at the > same time... > > > ......... > In this model, a "document collection", whether it be a database, a user, a > user group, a role, or a role group becomes the entity that the access > control documents are "authorizing". > > In this model, a "view" becomes an identifiable "collection" that can be > treated like a database. > Which would make creating views on top of other views becomes something > much easier to define/express. > > > I'm envisioning that to implement successful "access control" based views, > each "authorized entity" would have to maintain its own view index. > Otherwise it's really hard for me to imagine how a reduce function can > cache any precomputed results because it has no way of knowing that all the > underlying documents used in the reduce were authorized for the accessing > entity... All reduce functions would have to run in real time to ensure it > is only using authorized documents... > > If there were a separate index for each authorized entity though (and > especially if these entities were able to share index buckets where they > had all the same document access in common), then the reduce function would > cache data based on each authorized entity because it'd be built up from a > different view index. > > The existing model where indexes are updated whenever they are accessed > could remain in tact because you wouldn't have to rebuild indeces for > entities that weren't accessing that view... > > 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 "databases" would be quite > powerful... > > Regards, > Mike
Hi Mike, what you’ve described here is very very similar to what Jan is building. Adam
