Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-22733

Need SQL View like capability ..

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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

      { "state" = "NY" }

      . 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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              daniel.farrell Daniel Farrell
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: