Access Policies

⚠️ Only available in EdgeDB 2.0 or later.

This section describes the SDL declarations pertaining to access policies.

Examples

Declare a schema where users can only see their own profiles:

# Declare some global variables to store "current user"
# information.
global current_user_id -> uuid;
global current_user := (
    select User filter .id = global current_user_id
);
type User {
    required property name -> str;
}
type Profile {
    link owner -> User;
    # Only allow reading to the owner, but also
    # ensure that a user cannot set the "owner" link
    # to anything but themselves.
    access policy owner_only
        allow all using (.owner = global current_user);
}

Syntax

Define a new access policy corresponding to the more explicit DDL commands.

Access policy used inside a type declaration:
access policy name
  [ when (condition) ]
  { allow | deny } action [, action ... ]
  [ using (expr) ]
  [ annotation-declarations ] ;
where action is one of
all
select
insert
delete
update [{ read | write }]

Description

Access policies are used to implement object-level security and as such they are defined on object types. In practice the access policies often work together with global variables.

Access policies are an opt-in feature, so once at least one access policy is defined for a given type, all access not explicitly allowed by that policy becomes forbidden.

Any sub-type extending a base type also inherits all the access policies of the base type.

The access policy declaration options are as follows:

name

The name of the access policy.

when (condition)

Specifies which objects this policy applies to. The condition has to be a bool expression.

When omitted, it is assumed that this policy applies to all objects of a given type.

allow

Indicates that qualifying objects should allow access under this policy.

deny

Indicates that qualifying objects should not allow access under this policy. This flavor supersedes any allow policy and can be used to selectively deny access to a subset of objects that otherwise explicitly allows accessing them.

all

Apply the policy to all actions. It is exactly equivalent to listing select, insert, delete, update actions explicitly.

select

Apply the policy to all selection queries. Note that any object that cannot be selected, cannot be modified either. This makes select the most basic “visibility” policy.

insert

Apply the policy to all inserted objects. If a newly inserted object would violate this policy, an error is produced instead.

delete

Apply the policy to all objects about to be deleted. If an object does not allow access under this kind of policy, it is not going to be considered by any delete command.

Note that any object that cannot be selected, cannot be modified either.

update read

Apply the policy to all objects selected for an update. If an object does not allow access under this kind of policy, it is not visible cannot be updated.

Note that any object that cannot be selected, cannot be modified either.

update write

Apply the policy to all objects at the end of an update. If an updated object violates this policy, an error is produced instead.

Note that any object that cannot be selected, cannot be modified either.

update

This is just a shorthand for update read and update write.

Note that any object that cannot be selected, cannot be modified either.

using expr

Specifies what the policy is with respect to a given eligible (based on when clause) object. The expr has to be a bool expression. The specific meaning of this value also depends on whether this policy flavor is allow or deny.

When omitted, it is assumed that this policy applies to all eligible objects of a given type.

annotation-declarations

Set access policy annotation to a given value.

︙