-
Type: New Feature
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Concurrency, Querying, Security, Usability
-
None
I'd like to request the addition of a SQL View like capability for security.
To be as brief as possible-
. You have a collection with 8 keys. Remove all permission from this
collection for a given user. Create a view that references 6 of the 8
keys. Give permission to this view to the same user. Now this user
can read/write/whatever a vertical slice of this collection. This serves
a use case of data privacy.
OR, create the view with all columns, but a filter criteria is in place.
Eg., where
. Now this user can read/write/whatever
a horizontal slice of this collection. This serves a use case of data
privacy, and multi-tenancy.
–
. How others (SQL) does this-
The view either enforces the underlying security of the source/
referenced collections, or not.
By default, security is inherited from the source collection. If you
can't read/write the source table, the view will not give you this
ability. In this use case, the view acts more like a macro, and its
value add is to centralize definitions, or code.
If the view is created
{ "with_admin_authority" : true }, then the view
overrides base permissions. This is how you suppress access to
base collections, yet still poke through any read/write any subsets.
In this case, the user can do whatever read/write they were given
the view object, and not the underlying/base collection object.
You might also want a
{ "with_check_option" }. In effect, if you
should only see "NY", can you insert "NJ" ?
. Phase 1, I'd be happy with projection and filter, and we'll call these
"simple views". They are writable like a normal collection.
Phase 2, "compound views", containing aggregated keys or simply
keys that are calculated. MongoDB doesn't know how to simply write
back to a calculated key. You can read compound views, but not
update.
. Query optimizer enhancement-
If the view has a filter as part of its definition, and the user adds
filters, yadda, in their request, you should someday flatten all of that,
remove duplicates and such. This is a performance feature only.
. Views on views-
Added someday. Not needed on day one perhaps.
- duplicates
-
SERVER-10788 Writable views
- Backlog
-
SERVER-142 Read-only views over collection data.
- Closed