2022-03-16 03:39:21 +03:00
|
|
|
{-# LANGUAGE TypeFamilyDependencies #-}
|
2022-06-07 08:32:08 +03:00
|
|
|
{-# LANGUAGE ViewPatterns #-}
|
2022-03-16 03:39:21 +03:00
|
|
|
|
2018-06-27 16:11:32 +03:00
|
|
|
module Hasura.RQL.DDL.Permission
|
|
|
|
( CreatePerm,
|
2018-12-13 10:26:15 +03:00
|
|
|
runCreatePerm,
|
2018-06-27 16:11:32 +03:00
|
|
|
PermDef (..),
|
|
|
|
InsPerm (..),
|
|
|
|
InsPermDef,
|
|
|
|
buildInsPermInfo,
|
|
|
|
SelPerm (..),
|
|
|
|
SelPermDef,
|
|
|
|
buildSelPermInfo,
|
|
|
|
UpdPerm (..),
|
|
|
|
UpdPermDef,
|
|
|
|
buildUpdPermInfo,
|
|
|
|
DelPerm (..),
|
|
|
|
DelPermDef,
|
|
|
|
buildDelPermInfo,
|
2018-12-13 10:26:15 +03:00
|
|
|
DropPerm,
|
|
|
|
runDropPerm,
|
2020-12-08 17:22:31 +03:00
|
|
|
dropPermissionInMetadata,
|
2018-12-13 10:26:15 +03:00
|
|
|
SetPermComment (..),
|
|
|
|
runSetPermComment,
|
2022-04-06 15:47:35 +03:00
|
|
|
PermInfo,
|
|
|
|
buildPermInfo,
|
|
|
|
addPermissionToMetadata,
|
2018-06-27 16:11:32 +03:00
|
|
|
)
|
|
|
|
where
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-12-21 12:42:35 +03:00
|
|
|
import Control.Lens (Lens', (.~), (^?))
|
2020-08-27 19:36:39 +03:00
|
|
|
import Data.Aeson
|
2022-06-08 18:31:28 +03:00
|
|
|
import Data.Aeson.Key qualified as K
|
|
|
|
import Data.Aeson.KeyMap qualified as KM
|
2020-10-27 16:53:49 +03:00
|
|
|
import Data.HashMap.Strict qualified as HM
|
2020-12-08 17:22:31 +03:00
|
|
|
import Data.HashMap.Strict.InsOrd qualified as OMap
|
2020-10-27 16:53:49 +03:00
|
|
|
import Data.HashSet qualified as HS
|
2022-11-30 21:12:14 +03:00
|
|
|
import Data.Sequence qualified as Seq
|
2020-10-21 19:35:06 +03:00
|
|
|
import Data.Text.Extended
|
2021-05-11 18:18:31 +03:00
|
|
|
import Hasura.Base.Error
|
2019-03-18 19:22:21 +03:00
|
|
|
import Hasura.EncJSON
|
2020-08-27 19:36:39 +03:00
|
|
|
import Hasura.Prelude
|
2018-06-27 16:11:32 +03:00
|
|
|
import Hasura.RQL.DDL.Permission.Internal
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.IR.BoolExp
|
|
|
|
import Hasura.RQL.Types.Backend
|
|
|
|
import Hasura.RQL.Types.Column
|
|
|
|
import Hasura.RQL.Types.Common
|
|
|
|
import Hasura.RQL.Types.ComputedField
|
|
|
|
import Hasura.RQL.Types.Metadata
|
|
|
|
import Hasura.RQL.Types.Metadata.Backend
|
|
|
|
import Hasura.RQL.Types.Metadata.Object
|
|
|
|
import Hasura.RQL.Types.Permission
|
|
|
|
import Hasura.RQL.Types.Relationships.Local
|
|
|
|
import Hasura.RQL.Types.SchemaCache
|
|
|
|
import Hasura.RQL.Types.SchemaCache.Build
|
2022-08-19 18:40:26 +03:00
|
|
|
import Hasura.RQL.Types.SchemaCacheTypes
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Table
|
2021-03-15 16:02:58 +03:00
|
|
|
import Hasura.SQL.AnyBackend qualified as AB
|
2020-12-28 15:56:00 +03:00
|
|
|
import Hasura.SQL.Types
|
2021-01-19 22:14:42 +03:00
|
|
|
import Hasura.Session
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2020-04-24 12:10:53 +03:00
|
|
|
{- Note [Backend only permissions]
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
As of writing this note, Hasura permission system is meant to be used by the
|
|
|
|
frontend. After introducing "Actions", the webhook handlers now can make GraphQL
|
|
|
|
mutations to the server with some backend logic. These mutations shouldn't be
|
|
|
|
exposed to frontend for any user since they'll bypass the business logic.
|
|
|
|
|
2022-05-31 17:41:09 +03:00
|
|
|
Backend only permissions is available for all(insert/update/delete) mutation operations.
|
|
|
|
|
2020-04-24 12:10:53 +03:00
|
|
|
For example:-
|
2022-05-31 17:41:09 +03:00
|
|
|
=============
|
2020-04-24 12:10:53 +03:00
|
|
|
|
|
|
|
We've a table named "user" and it has a "email" column. We need to validate the
|
|
|
|
email address. So we define an action "create_user" and it expects the same inputs
|
2022-05-31 17:41:09 +03:00
|
|
|
as "insert_user" mutation (generated by Hasura). Note that both "create_user" and
|
|
|
|
"insert_user" can insert values into the "user" table but only "create_user" has the
|
|
|
|
logic to validate the email address.
|
|
|
|
|
|
|
|
In the current Hasura permission system, a role has permission for both 'actions' and
|
|
|
|
'insert operations' on the table. That means, both the "create_user" and "insert_user"
|
|
|
|
operations will be visible to the frontend client. This is bad, since users can use
|
|
|
|
"insert_user" operation to circumvent the validation logic of "create_user".
|
|
|
|
|
|
|
|
We can overcome this problem by using "Backend only permissions". In this if the
|
|
|
|
insert/update/delete permission is marked as "backend_only: true", then the insert
|
|
|
|
operation will not be visible to the frontend client unless specifically specified
|
2020-04-24 12:10:53 +03:00
|
|
|
|
|
|
|
Backend only permissions adds an additional privilege to Hasura generated operations.
|
2022-05-31 17:41:09 +03:00
|
|
|
|
|
|
|
Those are accessable only if the request is made with all of the following:
|
|
|
|
* `x-hasura-admin-secret` (if authorization is configured),
|
|
|
|
* `x-hasura-use-backend-only-permissions` (value must be set to "true"),
|
|
|
|
* `x-hasura-role` to identify the role
|
|
|
|
* other required session variables.
|
2020-04-24 12:10:53 +03:00
|
|
|
|
|
|
|
backend_only `x-hasura-admin-secret` `x-hasura-use-backend-only-permissions` Result
|
|
|
|
------------ --------------------- ------------------------------------- ------
|
2022-05-31 17:41:09 +03:00
|
|
|
FALSE ANY ANY Mutation is always visible (Default Case: When no authorization is setup)
|
2020-04-24 12:10:53 +03:00
|
|
|
TRUE FALSE ANY Mutation is always hidden
|
2022-05-31 17:41:09 +03:00
|
|
|
FALSE TRUE ANY Mutation is always visible
|
2020-04-24 12:10:53 +03:00
|
|
|
TRUE TRUE (OR NOT-SET) FALSE Mutation is hidden
|
|
|
|
TRUE TRUE (OR NOT-SET) TRUE Mutation is shown
|
|
|
|
|
2022-05-31 17:41:09 +03:00
|
|
|
case 1: default case - no authorization is set and no backend_only permission are set
|
|
|
|
then irresepective of the value of `x-hasura-use-backend-only-permissions` the
|
|
|
|
mutation will always be visible
|
|
|
|
|
|
|
|
case 2: the authorization is set and the backend_only permissions are set but the
|
|
|
|
`x-hasura-admin-secret` is not sent along with request then irresepective of the value
|
|
|
|
in `x-hasura-use-backend-only-permissions` the mutation will always be hidden
|
|
|
|
|
|
|
|
case 3: the authorization is set, but no backend_only permission are set, the
|
|
|
|
`x-hasura-admin-secret` is sent along with request then irresepective of the value
|
|
|
|
in `x-hasura-use-backend-only-permissions` the mutation will always be visible
|
|
|
|
|
|
|
|
case 4 and 5:
|
|
|
|
the authz is set and the backend_only permissions are also set and the
|
|
|
|
`x-hasura-admin` secret is also sent along with the request then:
|
|
|
|
* if `x-hasura-use-backend-only-permissions` header is sent as FALSE along with the
|
|
|
|
request then the mutation will be hidden (4th case)
|
|
|
|
* if `x-hasura-use-backend-only-permissions` header is sent as TRUE along with the
|
|
|
|
request then the mutation will be visible (5th case)
|
|
|
|
|
|
|
|
How it Works:-
|
|
|
|
===============
|
|
|
|
|
|
|
|
Hasura has two scenarios:
|
|
|
|
* Frontend Scenario
|
|
|
|
* Backend Scenario
|
|
|
|
|
|
|
|
When no backend-only permissions are set then Hasura runs only in frontend scenario,
|
|
|
|
i.e all the mutation operations are visible.
|
|
|
|
|
|
|
|
When backend-only permissions are set, there comes a notion of:
|
|
|
|
* which mutations are visible by default i.e without any request headers (frontend scenario)
|
|
|
|
* which mutations are visible when `x-hasura-use-backend-only-permissions` is set (backend scenario)
|
|
|
|
|
|
|
|
Hasura maintains two different graphql schema ('frontend schema' and 'backend schema')
|
|
|
|
for all mutation fields of a table:
|
|
|
|
* 'frontend schema': info about the mutation operation allowed to be shown on the frontend client when no backend-only permissions is set
|
|
|
|
* 'backend schema' : info about the mutation operation allowed to be shown on the frontend client when backend-only permissions is set
|
|
|
|
|
|
|
|
The generation of these schemas happen in the `buildSource` functions of
|
|
|
|
`buildRoleContext` and `buildRelayRoleContext` functions. The internal representation
|
|
|
|
of these schema's look like:
|
|
|
|
{RoleName: (Frontend Schema/Default Schema, Backend Schema)}
|
|
|
|
|
|
|
|
For example:
|
|
|
|
------------
|
|
|
|
We've a table "user" tracked by hasura and a role "public"
|
|
|
|
|
|
|
|
\* If the update permission for the table "user" is marked as backend_only then the
|
|
|
|
GQL context for that table will look like:
|
|
|
|
|
|
|
|
{"public": (["insert_user","delete_user"], ["update_user"])}
|
|
|
|
|
|
|
|
In the above '["insert_user","delete_user"]' are the only mutation operation visible
|
|
|
|
by default on the frontend client. And the 'update_user' opertaion is only visible
|
|
|
|
when the `x-hasura-use-backend-only-permissions` request header is present.
|
|
|
|
|
|
|
|
\* If there is no backend_only permissions defined on the role then the GQL context
|
|
|
|
looks like:
|
|
|
|
|
|
|
|
{"public": (["insert_user","delete_user", "update_user"], [])}
|
|
|
|
|
|
|
|
In the above there is no specific schema for the backend scenario i.e all the
|
|
|
|
mutation operations are visible by default.
|
|
|
|
-}
|
2019-02-11 15:45:30 +03:00
|
|
|
procSetObj ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
|
|
|
(QErrM m, BackendMetadata b) =>
|
2020-12-28 15:56:00 +03:00
|
|
|
SourceName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
|
|
|
Maybe (ColumnValues b Value) ->
|
2022-11-30 21:12:14 +03:00
|
|
|
m (PreSetColsPartial b, [Text], Seq SchemaDependency)
|
2020-12-28 15:56:00 +03:00
|
|
|
procSetObj source tn fieldInfoMap mObj = do
|
2019-08-17 00:35:22 +03:00
|
|
|
(setColTups, deps) <- withPathK "set" $
|
|
|
|
fmap unzip $
|
|
|
|
forM (HM.toList setObj) $ \(pgCol, val) -> do
|
2021-02-14 09:07:52 +03:00
|
|
|
ty <-
|
|
|
|
askColumnType fieldInfoMap pgCol $
|
2019-02-11 15:45:30 +03:00
|
|
|
"column " <> pgCol <<> " not found in table " <>> tn
|
2021-02-14 09:07:52 +03:00
|
|
|
sqlExp <- parseCollectableType (CollectableTypeScalar ty) val
|
2021-04-22 00:44:37 +03:00
|
|
|
let dep = mkColDep @b (getDepReason sqlExp) source tn pgCol
|
2019-08-17 00:35:22 +03:00
|
|
|
return ((pgCol, sqlExp), dep)
|
2022-11-30 21:12:14 +03:00
|
|
|
return (HM.fromList setColTups, depHeaders, Seq.fromList deps)
|
2019-02-11 15:45:30 +03:00
|
|
|
where
|
|
|
|
setObj = fromMaybe mempty mObj
|
2022-06-08 18:31:28 +03:00
|
|
|
depHeaders =
|
|
|
|
getDepHeadersFromVal $
|
|
|
|
Object $
|
|
|
|
KM.fromList $
|
|
|
|
map (first (K.fromText . toTxt)) $
|
|
|
|
HM.toList setObj
|
2019-02-11 15:45:30 +03:00
|
|
|
|
2019-08-17 00:35:22 +03:00
|
|
|
getDepReason = bool DRSessionVariable DROnType . isStaticValue
|
|
|
|
|
2022-04-06 15:47:35 +03:00
|
|
|
type family PermInfo perm where
|
|
|
|
PermInfo SelPerm = SelPermInfo
|
|
|
|
PermInfo InsPerm = InsPermInfo
|
|
|
|
PermInfo UpdPerm = UpdPermInfo
|
|
|
|
PermInfo DelPerm = DelPermInfo
|
|
|
|
|
|
|
|
addPermissionToMetadata ::
|
|
|
|
PermDef b a ->
|
|
|
|
TableMetadata b ->
|
|
|
|
TableMetadata b
|
|
|
|
addPermissionToMetadata permDef = case _pdPermission permDef of
|
|
|
|
InsPerm' _ -> tmInsertPermissions %~ OMap.insert (_pdRole permDef) permDef
|
|
|
|
SelPerm' _ -> tmSelectPermissions %~ OMap.insert (_pdRole permDef) permDef
|
|
|
|
UpdPerm' _ -> tmUpdatePermissions %~ OMap.insert (_pdRole permDef) permDef
|
|
|
|
DelPerm' _ -> tmDeletePermissions %~ OMap.insert (_pdRole permDef) permDef
|
|
|
|
|
|
|
|
buildPermInfo ::
|
2022-08-19 18:40:26 +03:00
|
|
|
( BackendMetadata b,
|
|
|
|
QErrM m,
|
|
|
|
TableCoreInfoRM b m,
|
|
|
|
GetAggregationPredicatesDeps b
|
|
|
|
) =>
|
2022-04-06 15:47:35 +03:00
|
|
|
SourceName ->
|
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
2022-06-07 08:32:08 +03:00
|
|
|
RoleName ->
|
2022-04-06 15:47:35 +03:00
|
|
|
PermDefPermission b perm ->
|
|
|
|
m (WithDeps (PermInfo perm b))
|
2022-08-25 11:23:16 +03:00
|
|
|
buildPermInfo x1 x2 x3 roleName = \case
|
|
|
|
SelPerm' p -> buildSelPermInfo x1 x2 x3 roleName p
|
2022-04-06 15:47:35 +03:00
|
|
|
InsPerm' p -> buildInsPermInfo x1 x2 x3 p
|
|
|
|
UpdPerm' p -> buildUpdPermInfo x1 x2 x3 p
|
|
|
|
DelPerm' p -> buildDelPermInfo x1 x2 x3 p
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-07-17 00:18:58 +03:00
|
|
|
doesPermissionExistInMetadata ::
|
2021-12-21 12:42:35 +03:00
|
|
|
forall b.
|
2021-07-17 00:18:58 +03:00
|
|
|
TableMetadata b ->
|
|
|
|
RoleName ->
|
|
|
|
PermType ->
|
|
|
|
Bool
|
|
|
|
doesPermissionExistInMetadata tableMetadata roleName = \case
|
2021-12-21 12:42:35 +03:00
|
|
|
PTInsert -> hasPermissionTo tmInsertPermissions
|
|
|
|
PTSelect -> hasPermissionTo tmSelectPermissions
|
|
|
|
PTUpdate -> hasPermissionTo tmUpdatePermissions
|
|
|
|
PTDelete -> hasPermissionTo tmDeletePermissions
|
|
|
|
where
|
|
|
|
hasPermissionTo :: forall a. Lens' (TableMetadata b) (Permissions a) -> Bool
|
|
|
|
hasPermissionTo perms = isJust $ tableMetadata ^? perms . ix roleName
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2020-11-12 12:25:48 +03:00
|
|
|
runCreatePerm ::
|
2021-03-15 16:02:58 +03:00
|
|
|
forall m b a.
|
2022-04-06 15:47:35 +03:00
|
|
|
(UserInfoM m, CacheRWM m, MonadError QErr m, MetadataM m, BackendMetadata b) =>
|
2021-06-09 22:42:37 +03:00
|
|
|
CreatePerm a b ->
|
|
|
|
m EncJSON
|
2021-07-17 00:18:58 +03:00
|
|
|
runCreatePerm (CreatePerm (WithTable source tableName permissionDefn)) = do
|
|
|
|
tableMetadata <- askTableMetadata @b source tableName
|
2022-04-06 15:47:35 +03:00
|
|
|
let permissionType = reflectPermDefPermission (_pdPermission permissionDefn)
|
2021-07-17 00:18:58 +03:00
|
|
|
ptText = permTypeToCode permissionType
|
|
|
|
role = _pdRole permissionDefn
|
2021-03-15 16:02:58 +03:00
|
|
|
metadataObject =
|
|
|
|
MOSourceObjId source $
|
|
|
|
AB.mkAnyBackend $
|
2021-07-17 00:18:58 +03:00
|
|
|
SMOTableObj @b tableName $
|
|
|
|
MTOPerm role permissionType
|
|
|
|
|
|
|
|
-- NOTE: we check if a permission exists for a `(table, role)` entity in the metadata
|
|
|
|
-- and not in the `RolePermInfoMap b` because there may exist a permission for the `role`
|
|
|
|
-- which is an inherited one, so we check it in the metadata directly
|
|
|
|
|
|
|
|
-- The metadata will not contain the permissions for the admin role,
|
|
|
|
-- because the graphql-engine automatically creates the role and it's
|
|
|
|
-- assumed that the admin role is an implicit role of the graphql-engine.
|
|
|
|
when (doesPermissionExistInMetadata tableMetadata role permissionType || role == adminRoleName) $
|
|
|
|
throw400 AlreadyExists $
|
|
|
|
ptText <> " permission already defined on table " <> tableName <<> " with role " <>> role
|
2020-12-08 17:22:31 +03:00
|
|
|
buildSchemaCacheFor metadataObject $
|
|
|
|
MetadataModifier $
|
2022-04-06 15:47:35 +03:00
|
|
|
tableMetadataSetter @b source tableName %~ addPermissionToMetadata permissionDefn
|
2020-11-12 12:25:48 +03:00
|
|
|
pure successMsg
|
|
|
|
|
|
|
|
runDropPerm ::
|
2022-04-06 15:47:35 +03:00
|
|
|
forall b m.
|
|
|
|
(UserInfoM m, CacheRWM m, MonadError QErr m, MetadataM m, BackendMetadata b) =>
|
|
|
|
PermType ->
|
|
|
|
DropPerm b ->
|
2021-04-22 00:44:37 +03:00
|
|
|
m EncJSON
|
2022-04-06 15:47:35 +03:00
|
|
|
runDropPerm permType (DropPerm source table role) = do
|
2021-07-17 00:18:58 +03:00
|
|
|
tableMetadata <- askTableMetadata @b source table
|
|
|
|
unless (doesPermissionExistInMetadata tableMetadata role permType) $ do
|
An `ErrorMessage` type, to encapsulate.
This introduces an `ErrorMessage` newtype which wraps `Text` in a manner which is designed to be easy to construct, and difficult to deconstruct.
It provides functionality similar to `Data.Text.Extended`, but designed _only_ for error messages. Error messages are constructed through `fromString`, concatenation, or the `toErrorValue` function, which is designed to be overridden for all meaningful domain types that might show up in an error message. Notably, there are not and should never be instances of `ToErrorValue` for `String`, `Text`, `Int`, etc. This is so that we correctly represent the value in a way that is specific to its type. For example, all `Name` values (from the _graphql-parser-hs_ library) are single-quoted now; no exceptions.
I have mostly had to add `instance ToErrorValue` for various backend types (and also add newtypes where necessary). Some of these are not strictly necessary for this changeset, as I had bigger aspirations when I started. These aspirations have been tempered by trying and failing twice.
As such, in this changeset, I have started by introducing this type to the `parseError` and `parseErrorWith` functions. In the future, I would like to extend this to the `QErr` record and the various `throwError` functions, but this is a much larger task and should probably be done in stages.
For now, `toErrorMessage` and `fromErrorMessage` are provided for conversion to and from `Text`, but the intent is to stop exporting these once all error messages are converted to the new type.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5018
GitOrigin-RevId: 84b37e238992e4312255a87ca44f41af65e2d89a
2022-07-18 23:26:01 +03:00
|
|
|
let errMsg = permTypeToCode permType <> " permission on " <> table <<> " for role " <> role <<> " does not exist"
|
2021-07-17 00:18:58 +03:00
|
|
|
throw400 PermissionDenied errMsg
|
2020-12-08 17:22:31 +03:00
|
|
|
withNewInconsistentObjsCheck $
|
|
|
|
buildSchemaCache $
|
|
|
|
MetadataModifier $
|
2021-04-22 00:44:37 +03:00
|
|
|
tableMetadataSetter @b source table %~ dropPermissionInMetadata role permType
|
2020-11-12 12:25:48 +03:00
|
|
|
return successMsg
|
|
|
|
|
2018-06-27 16:11:32 +03:00
|
|
|
buildInsPermInfo ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
2022-08-19 18:40:26 +03:00
|
|
|
( QErrM m,
|
|
|
|
TableCoreInfoRM b m,
|
|
|
|
BackendMetadata b,
|
|
|
|
GetAggregationPredicatesDeps b
|
|
|
|
) =>
|
2020-12-28 15:56:00 +03:00
|
|
|
SourceName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
2022-04-06 15:47:35 +03:00
|
|
|
InsPerm b ->
|
2021-02-14 09:07:52 +03:00
|
|
|
m (WithDeps (InsPermInfo b))
|
2022-05-31 17:41:09 +03:00
|
|
|
buildInsPermInfo source tn fieldInfoMap (InsPerm checkCond set mCols backendOnly) =
|
2019-04-17 12:48:41 +03:00
|
|
|
withPathK "permission" $ do
|
2020-12-28 15:56:00 +03:00
|
|
|
(be, beDeps) <- withPathK "check" $ procBoolExp source tn fieldInfoMap checkCond
|
|
|
|
(setColsSQL, setHdrs, setColDeps) <- procSetObj source tn fieldInfoMap set
|
2019-12-15 19:07:08 +03:00
|
|
|
void $
|
2021-12-21 12:42:35 +03:00
|
|
|
withPathK "columns" $ do
|
|
|
|
indexedForM insCols $ \col -> do
|
|
|
|
-- Check that all columns specified do in fact exist and are columns
|
|
|
|
_ <- askColumnType fieldInfoMap col relInInsErr
|
|
|
|
-- Check that the column is insertable
|
|
|
|
ci <- askColInfo fieldInfoMap col ""
|
2022-01-19 11:37:50 +03:00
|
|
|
unless (_cmIsInsertable $ ciMutability ci) $
|
2021-12-21 12:42:35 +03:00
|
|
|
throw500
|
|
|
|
( "Column "
|
|
|
|
<> col
|
|
|
|
<<> " is not insertable and so cannot have insert permissions defined"
|
|
|
|
)
|
|
|
|
|
2020-02-13 10:38:49 +03:00
|
|
|
let fltrHeaders = getDependentHeaders checkCond
|
2021-08-09 13:20:04 +03:00
|
|
|
reqHdrs = fltrHeaders `HS.union` (HS.fromList setHdrs)
|
2022-11-30 21:12:14 +03:00
|
|
|
insColDeps = mkColDep @b DRUntyped source tn <$> insCols
|
|
|
|
deps = mkParentDep @b source tn Seq.:<| beDeps <> setColDeps <> Seq.fromList insColDeps
|
|
|
|
insColsWithoutPresets = HS.fromList insCols `HS.difference` HM.keysSet setColsSQL
|
2021-12-21 12:42:35 +03:00
|
|
|
|
2022-11-30 21:12:14 +03:00
|
|
|
return (InsPermInfo insColsWithoutPresets be setColsSQL backendOnly reqHdrs, deps)
|
2018-06-27 16:11:32 +03:00
|
|
|
where
|
2022-02-03 17:14:33 +03:00
|
|
|
allInsCols = map ciColumn $ filter (_cmIsInsertable . ciMutability) $ getCols fieldInfoMap
|
|
|
|
insCols = interpColSpec allInsCols (fromMaybe PCStar mCols)
|
2021-12-21 12:42:35 +03:00
|
|
|
relInInsErr = "Only table columns can have insert permissions defined, not relationships or other field types"
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
-- | validate the values present in the `query_root_fields` and the `subscription_root_fields`
|
|
|
|
-- present in the select permission
|
|
|
|
validateAllowedRootFields ::
|
|
|
|
forall b m.
|
|
|
|
(QErrM m, TableCoreInfoRM b m, BackendMetadata b) =>
|
|
|
|
SourceName ->
|
|
|
|
TableName b ->
|
|
|
|
RoleName ->
|
|
|
|
SelPerm b ->
|
|
|
|
m (AllowedRootFields QueryRootFieldType, AllowedRootFields SubscriptionRootFieldType)
|
2022-08-25 11:23:16 +03:00
|
|
|
validateAllowedRootFields sourceName tableName roleName SelPerm {..} = do
|
2022-06-07 08:32:08 +03:00
|
|
|
tableCoreInfo <- lookupTableCoreInfo @b tableName >>= (`onNothing` (throw500 $ "unexpected: table not found " <>> tableName))
|
|
|
|
|
|
|
|
-- validate the query_root_fields and subscription_root_fields values
|
|
|
|
let needToValidatePrimaryKeyRootField =
|
|
|
|
QRFTSelectByPk
|
|
|
|
`rootFieldNeedsValidation` spAllowedQueryRootFields
|
|
|
|
|| SRFTSelectByPk
|
|
|
|
`rootFieldNeedsValidation` spAllowedSubscriptionRootFields
|
|
|
|
needToValidateAggregationRootField =
|
|
|
|
QRFTSelectAggregate
|
|
|
|
`rootFieldNeedsValidation` spAllowedQueryRootFields
|
|
|
|
|| SRFTSelectAggregate
|
|
|
|
`rootFieldNeedsValidation` spAllowedSubscriptionRootFields
|
|
|
|
|
|
|
|
when needToValidatePrimaryKeyRootField $ validatePrimaryKeyRootField tableCoreInfo
|
|
|
|
when needToValidateAggregationRootField $ validateAggregationRootField
|
|
|
|
|
|
|
|
pure (spAllowedQueryRootFields, spAllowedSubscriptionRootFields)
|
|
|
|
where
|
|
|
|
rootFieldNeedsValidation rootField = \case
|
|
|
|
ARFAllowAllRootFields -> False
|
|
|
|
ARFAllowConfiguredRootFields allowedRootFields -> rootField `HS.member` allowedRootFields
|
|
|
|
|
|
|
|
pkValidationError =
|
|
|
|
throw400 ValidationFailed $
|
|
|
|
"The \"select_by_pk\" field cannot be included in the query_root_fields or subscription_root_fields"
|
|
|
|
<> " because the role "
|
|
|
|
<> roleName
|
|
|
|
<<> " does not have access to the primary key of the table "
|
|
|
|
<> tableName
|
|
|
|
<<> " in the source "
|
|
|
|
<>> sourceName
|
|
|
|
validatePrimaryKeyRootField TableCoreInfo {..} =
|
|
|
|
case _tciPrimaryKey of
|
|
|
|
Nothing -> pkValidationError
|
|
|
|
Just (PrimaryKey _ pkCols) ->
|
|
|
|
case spColumns of
|
|
|
|
PCStar -> pure ()
|
|
|
|
PCCols (HS.fromList -> selPermCols) ->
|
|
|
|
-- Check if all the primary key columns of the table are
|
|
|
|
-- accessible to the current role
|
|
|
|
unless (all ((`HS.member` selPermCols) . ciColumn) pkCols) pkValidationError
|
|
|
|
|
|
|
|
validateAggregationRootField =
|
|
|
|
unless spAllowAggregations $
|
|
|
|
throw400 ValidationFailed $
|
|
|
|
"The \"select_aggregate\" root field can only be enabled in the query_root_fields or "
|
|
|
|
<> " the subscription_root_fields when \"allow_aggregations\" is set to true"
|
|
|
|
|
2018-06-27 16:11:32 +03:00
|
|
|
buildSelPermInfo ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
2022-08-19 18:40:26 +03:00
|
|
|
( QErrM m,
|
|
|
|
TableCoreInfoRM b m,
|
|
|
|
BackendMetadata b,
|
|
|
|
GetAggregationPredicatesDeps b
|
|
|
|
) =>
|
2020-12-28 15:56:00 +03:00
|
|
|
SourceName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
2022-06-07 08:32:08 +03:00
|
|
|
RoleName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
SelPerm b ->
|
|
|
|
m (WithDeps (SelPermInfo b))
|
2022-08-25 11:23:16 +03:00
|
|
|
buildSelPermInfo source tableName fieldInfoMap roleName sp = withPathK "permission" $ do
|
2022-11-30 21:12:14 +03:00
|
|
|
let pgCols = interpColSpec (ciColumn <$> getCols fieldInfoMap) $ spColumns sp
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
(spiFilter, boolExpDeps) <-
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
withPathK "filter" $
|
2022-06-07 08:32:08 +03:00
|
|
|
procBoolExp source tableName fieldInfoMap $
|
|
|
|
spFilter sp
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
-- check if the columns exist
|
|
|
|
void $
|
|
|
|
withPathK "columns" $
|
|
|
|
indexedForM pgCols $ \pgCol ->
|
2021-02-14 09:07:52 +03:00
|
|
|
askColumnType fieldInfoMap pgCol autoInferredErr
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2019-10-18 11:29:47 +03:00
|
|
|
-- validate computed fields
|
2022-06-06 10:23:00 +03:00
|
|
|
validComputedFields <-
|
2019-11-07 17:39:48 +03:00
|
|
|
withPathK "computed_fields" $
|
|
|
|
indexedForM computedFields $ \fieldName -> do
|
|
|
|
computedFieldInfo <- askComputedFieldInfo fieldInfoMap fieldName
|
2022-05-25 13:24:41 +03:00
|
|
|
case computedFieldReturnType @b (_cfiReturnType computedFieldInfo) of
|
|
|
|
ReturnsScalar _ -> pure fieldName
|
|
|
|
ReturnsTable returnTable ->
|
2019-11-07 17:39:48 +03:00
|
|
|
throw400 NotSupported $
|
|
|
|
"select permissions on computed field "
|
|
|
|
<> fieldName
|
|
|
|
<<> " are auto-derived from the permissions on its returning table "
|
|
|
|
<> returnTable
|
|
|
|
<<> " and cannot be specified manually"
|
2022-06-07 19:49:13 +03:00
|
|
|
ReturnsOthers -> pure fieldName
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-04-22 00:44:37 +03:00
|
|
|
let deps =
|
2022-06-07 08:32:08 +03:00
|
|
|
mkParentDep @b source tableName
|
2022-11-30 21:12:14 +03:00
|
|
|
Seq.:<| boolExpDeps
|
|
|
|
<> (mkColDep @b DRUntyped source tableName <$> Seq.fromList pgCols)
|
|
|
|
<> (mkComputedFieldDep @b DRUntyped source tableName <$> Seq.fromList validComputedFields)
|
2022-06-07 08:32:08 +03:00
|
|
|
spiRequiredHeaders = getDependentHeaders $ spFilter sp
|
|
|
|
spiLimit = spLimit sp
|
2018-08-06 15:15:08 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
withPathK "limit" $ for_ spiLimit \value ->
|
2022-04-27 18:36:02 +03:00
|
|
|
when (value < 0) $
|
|
|
|
throw400 NotSupported "unexpected negative value"
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
let spiCols = HM.fromList $ map (,Nothing) pgCols
|
|
|
|
spiComputedFields = HS.toMap (HS.fromList validComputedFields) $> Nothing
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
(spiAllowedQueryRootFields, spiAllowedSubscriptionRootFields) <-
|
2022-08-25 11:23:16 +03:00
|
|
|
validateAllowedRootFields source tableName roleName sp
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
|
2022-06-07 08:32:08 +03:00
|
|
|
return (SelPermInfo {..}, deps)
|
2018-06-27 16:11:32 +03:00
|
|
|
where
|
2022-06-07 08:32:08 +03:00
|
|
|
spiAllowAgg = spAllowAggregations sp
|
2019-10-18 11:29:47 +03:00
|
|
|
computedFields = spComputedFields sp
|
2018-06-27 16:11:32 +03:00
|
|
|
autoInferredErr = "permissions for relationships are automatically inferred"
|
|
|
|
|
|
|
|
buildUpdPermInfo ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
2022-08-19 18:40:26 +03:00
|
|
|
( QErrM m,
|
|
|
|
TableCoreInfoRM b m,
|
|
|
|
BackendMetadata b,
|
|
|
|
GetAggregationPredicatesDeps b
|
|
|
|
) =>
|
2020-12-28 15:56:00 +03:00
|
|
|
SourceName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
|
|
|
UpdPerm b ->
|
|
|
|
m (WithDeps (UpdPermInfo b))
|
2022-05-31 17:41:09 +03:00
|
|
|
buildUpdPermInfo source tn fieldInfoMap (UpdPerm colSpec set fltr check backendOnly) = do
|
2018-06-27 16:11:32 +03:00
|
|
|
(be, beDeps) <-
|
|
|
|
withPathK "filter" $
|
2020-12-28 15:56:00 +03:00
|
|
|
procBoolExp source tn fieldInfoMap fltr
|
2020-04-24 12:10:53 +03:00
|
|
|
|
2020-12-28 15:56:00 +03:00
|
|
|
checkExpr <- traverse (withPathK "check" . procBoolExp source tn fieldInfoMap) check
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2020-12-28 15:56:00 +03:00
|
|
|
(setColsSQL, setHeaders, setColDeps) <- procSetObj source tn fieldInfoMap set
|
2019-02-11 15:45:30 +03:00
|
|
|
|
2018-06-27 16:11:32 +03:00
|
|
|
-- check if the columns exist
|
2019-06-21 14:04:21 +03:00
|
|
|
void $
|
|
|
|
withPathK "columns" $
|
2021-12-21 12:42:35 +03:00
|
|
|
indexedForM updCols $ \updCol -> do
|
|
|
|
-- Check that all columns specified do in fact exist and are columns
|
|
|
|
_ <- askColumnType fieldInfoMap updCol relInUpdErr
|
|
|
|
-- Check that the column is updatable
|
|
|
|
ci <- askColInfo fieldInfoMap updCol ""
|
2022-01-19 11:37:50 +03:00
|
|
|
unless (_cmIsUpdatable $ ciMutability ci) $
|
2021-12-21 12:42:35 +03:00
|
|
|
throw500
|
|
|
|
( "Column "
|
|
|
|
<> updCol
|
|
|
|
<<> " is not updatable and so cannot have update permissions defined"
|
|
|
|
)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2022-11-30 21:12:14 +03:00
|
|
|
let updColDeps = mkColDep @b DRUntyped source tn <$> updCols
|
|
|
|
deps = mkParentDep @b source tn Seq.:<| beDeps <> maybe mempty snd checkExpr <> Seq.fromList updColDeps <> setColDeps
|
2018-06-27 16:11:32 +03:00
|
|
|
depHeaders = getDependentHeaders fltr
|
2021-08-09 13:20:04 +03:00
|
|
|
reqHeaders = depHeaders `HS.union` (HS.fromList setHeaders)
|
2022-11-30 21:12:14 +03:00
|
|
|
updColsWithoutPreSets = HS.fromList updCols `HS.difference` HM.keysSet setColsSQL
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2022-11-30 21:12:14 +03:00
|
|
|
return (UpdPermInfo updColsWithoutPreSets tn be (fst <$> checkExpr) setColsSQL backendOnly reqHeaders, deps)
|
2018-06-27 16:11:32 +03:00
|
|
|
where
|
2022-02-03 17:14:33 +03:00
|
|
|
allUpdCols = map ciColumn $ filter (_cmIsUpdatable . ciMutability) $ getCols fieldInfoMap
|
|
|
|
updCols = interpColSpec allUpdCols colSpec
|
2021-12-21 12:42:35 +03:00
|
|
|
relInUpdErr = "Only table columns can have update permissions defined, not relationships or other field types"
|
2018-06-27 16:11:32 +03:00
|
|
|
|
|
|
|
buildDelPermInfo ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
2022-08-19 18:40:26 +03:00
|
|
|
( QErrM m,
|
|
|
|
TableCoreInfoRM b m,
|
|
|
|
BackendMetadata b,
|
|
|
|
GetAggregationPredicatesDeps b
|
|
|
|
) =>
|
2020-12-28 15:56:00 +03:00
|
|
|
SourceName ->
|
2021-02-14 09:07:52 +03:00
|
|
|
TableName b ->
|
|
|
|
FieldInfoMap (FieldInfo b) ->
|
|
|
|
DelPerm b ->
|
|
|
|
m (WithDeps (DelPermInfo b))
|
2022-05-31 17:41:09 +03:00
|
|
|
buildDelPermInfo source tn fieldInfoMap (DelPerm fltr backendOnly) = do
|
2018-06-27 16:11:32 +03:00
|
|
|
(be, beDeps) <-
|
|
|
|
withPathK "filter" $
|
2020-12-28 15:56:00 +03:00
|
|
|
procBoolExp source tn fieldInfoMap fltr
|
2022-11-30 21:12:14 +03:00
|
|
|
let deps = mkParentDep @b source tn Seq.:<| beDeps
|
2018-06-27 16:11:32 +03:00
|
|
|
depHeaders = getDependentHeaders fltr
|
2022-05-31 17:41:09 +03:00
|
|
|
return (DelPermInfo tn be backendOnly depHeaders, deps)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
data SetPermComment b = SetPermComment
|
2022-08-01 12:32:04 +03:00
|
|
|
{ apSource :: SourceName,
|
|
|
|
apTable :: TableName b,
|
|
|
|
apRole :: RoleName,
|
|
|
|
apPermission :: PermType,
|
|
|
|
apComment :: Maybe Text
|
Clean metadata arguments
## Description
Thanks to #1664, the Metadata API types no longer require a `ToJSON` instance. This PR follows up with a cleanup of the types of the arguments to the metadata API:
- whenever possible, it moves those argument types to where they're used (RQL.DDL.*)
- it removes all unrequired instances (mostly `ToJSON`)
This PR does not attempt to do it for _all_ such argument types. For some of the metadata operations, the type used to describe the argument to the API and used to represent the value in the metadata are one and the same (like for `CreateEndpoint`). Sometimes, the two types are intertwined in complex ways (`RemoteRelationship` and `RemoteRelationshipDef`). In the spirit of only doing uncontroversial cleaning work, this PR only moves types that are not used outside of RQL.DDL.
Furthermore, this is a small step towards separating the different types all jumbled together in RQL.Types.
## Notes
This PR also improves several `FromJSON` instances to make use of `withObject`, and to use a human readable string instead of a type name in error messages whenever possible. For instance:
- before: `expected Object for Object, but encountered X`
after: `expected Object for add computed field, but encountered X`
- before: `Expecting an object for update query`
after: `expected Object for update query, but encountered X`
This PR also renames `CreateFunctionPermission` to `FunctionPermissionArgument`, to remove the quite surprising `type DropFunctionPermission = CreateFunctionPermission`.
This PR also deletes some dead code, mostly in RQL.DML.
This PR also moves a PG-specific source resolving function from DDL.Schema.Source to the only place where it is used: App.hs.
https://github.com/hasura/graphql-engine-mono/pull/1844
GitOrigin-RevId: a594521194bb7fe6a111b02a9e099896f9fed59c
2021-07-27 13:41:42 +03:00
|
|
|
}
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
instance (Backend b) => FromJSON (SetPermComment b) where
|
2021-09-20 22:49:33 +03:00
|
|
|
parseJSON = withObject "SetPermComment" $ \o ->
|
2020-12-28 15:56:00 +03:00
|
|
|
SetPermComment
|
|
|
|
<$> o .:? "source" .!= defaultSource
|
|
|
|
<*> o .: "table"
|
|
|
|
<*> o .: "role"
|
|
|
|
<*> o .: "permission"
|
|
|
|
<*> o .:? "comment"
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2018-12-13 10:26:15 +03:00
|
|
|
runSetPermComment ::
|
2021-04-22 00:44:37 +03:00
|
|
|
forall b m.
|
2021-03-15 16:02:58 +03:00
|
|
|
(QErrM m, CacheRWM m, MetadataM m, BackendMetadata b) =>
|
2021-04-22 00:44:37 +03:00
|
|
|
SetPermComment b ->
|
|
|
|
m EncJSON
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
runSetPermComment (SetPermComment source table roleName permType comment) = do
|
2022-04-26 18:12:47 +03:00
|
|
|
tableInfo <- askTableInfo @b source table
|
2020-12-28 15:56:00 +03:00
|
|
|
|
|
|
|
-- assert permission exists and return appropriate permission modifier
|
|
|
|
permModifier <- case permType of
|
|
|
|
PTInsert -> do
|
2022-04-06 15:47:35 +03:00
|
|
|
assertPermDefined roleName PTInsert tableInfo
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
pure $ tmInsertPermissions . ix roleName . pdComment .~ comment
|
2020-12-28 15:56:00 +03:00
|
|
|
PTSelect -> do
|
2022-04-06 15:47:35 +03:00
|
|
|
assertPermDefined roleName PTSelect tableInfo
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
pure $ tmSelectPermissions . ix roleName . pdComment .~ comment
|
2020-12-28 15:56:00 +03:00
|
|
|
PTUpdate -> do
|
2022-04-06 15:47:35 +03:00
|
|
|
assertPermDefined roleName PTUpdate tableInfo
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
pure $ tmUpdatePermissions . ix roleName . pdComment .~ comment
|
2020-12-28 15:56:00 +03:00
|
|
|
PTDelete -> do
|
2022-04-06 15:47:35 +03:00
|
|
|
assertPermDefined roleName PTDelete tableInfo
|
[Preview] Inherited roles for postgres read queries
fixes #3868
docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`
Note:
To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.
Introduction
------------
This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.
How are select permissions of different roles are combined?
------------------------------------------------------------
A select permission includes 5 things:
1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role
Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.
Let's say the following GraphQL query is queried with the `combined_roles` role.
```graphql
query {
employees {
address
phone
}
}
```
This will translate to the following SQL query:
```sql
select
(case when (P1 or P2) then address else null end) as address,
(case when P2 then phone else null end) as phone
from employee
where (P1 or P2)
```
The other parameters of the select permission will be combined in the following manner:
1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example
APIs for inherited roles:
----------------------
1. `add_inherited_role`
`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments
`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)
Example:
```json
{
"type": "add_inherited_role",
"args": {
"role_name":"combined_user",
"role_set":[
"user",
"user1"
]
}
}
```
After adding the inherited role, the inherited role can be used like single roles like earlier
Note:
An inherited role can only be created with non-inherited/singular roles.
2. `drop_inherited_role`
The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:
`role_name`: name of the inherited role to be dropped
Example:
```json
{
"type": "drop_inherited_role",
"args": {
"role_name":"combined_user"
}
}
```
Metadata
---------
The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.
```json
{
"experimental_features": {
"derived_roles": [
{
"role_name": "manager_is_employee_too",
"role_set": [
"employee",
"manager"
]
}
]
}
}
```
Scope
------
Only postgres queries and subscriptions are supported in this PR.
Important points:
-----------------
1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.
TODOs
-------
- [ ] Tests
- [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
- [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
- [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 14:14:13 +03:00
|
|
|
pure $ tmDeletePermissions . ix roleName . pdComment .~ comment
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-03-15 16:02:58 +03:00
|
|
|
let metadataObject =
|
|
|
|
MOSourceObjId source $
|
|
|
|
AB.mkAnyBackend $
|
2021-04-22 00:44:37 +03:00
|
|
|
SMOTableObj @b table $
|
2021-03-15 16:02:58 +03:00
|
|
|
MTOPerm roleName permType
|
2020-12-28 15:56:00 +03:00
|
|
|
buildSchemaCacheFor metadataObject $
|
|
|
|
MetadataModifier $
|
2021-04-22 00:44:37 +03:00
|
|
|
tableMetadataSetter @b source table %~ permModifier
|
2020-12-28 15:56:00 +03:00
|
|
|
pure successMsg
|