@permission

Use the @permission directive to manage access permissions on your projections.

Example

This example shows how the @permission directive can be applied to a complete projection:

user.graphql

type User
    @upsertOn(...)
    @permission(
        read: ["USER_READ","USER_WRITE"]
        readById: ["USER_READ","USER_WRITE"]
        update: ["USER_WRITE"]
        create: ["USER_WRITE"]
        delete: ["USER_WRITE"]
        all: ["USER_WRITE"]
    ) {
    // ...
}

In this case, the User projection is only available for reading by the USER_READ and USER_WRITE permissions. However, the USER_WRITE permission can perform all operations on the projection. Further explanations on how to use the @permission directive can be found below.

General Explanation

These are some overall guidelines on how the permission directive works:

Specifying @permission without any arguments makes the projection unavailable for anyone.
Specifying the all argument allows all operations for the listed permissions.
The readById argument allows reading a single entry by its ID for the listed permissions.
Not specifying an argument will make the corresponding operations publicly available (as soon as the all argument is specified no operation is public anymore).
The FRAYM_AUTH_OWNER permission can perform all operations on all projections regardless of which permissions are specified.

Scope of the @permission Directive

The id, createdAt and changedAt fields are publicly available by default. You can change this behavior by adding a permission on the type level while specifying these fields in your schema.

Allow All Operations

This is how you can allow all operations for a specific permission:

@permission(read: ["USER"], readById: ["USER"], update: ["USER"], create: ["USER"], delete: ["USER"])

This statement allows the USER permission to read, update, create, and delete data. The following statement is equal to the one above:

@permission(all: ["USER"])

All Combined with a Specific Operation

The following statement will make the read, update, create and delete operations available to the ADMIN permission:

@permission(read: ["USER_READ"], all: ["ADMIN"])

The read operation is available to the USER_READ permission, too.

Multiple Permissions

Operations can be assigned to multiple permissions. The all can be used in addition to other operations as well.

Empty Set of Operations

This is how you can disallow all operations on a specific field:

@permission(all: [])

The following statement is equal to the one above:

@permission

This means that no permissions are allowed to read, update, create, or delete data.

The FRAYM_AUTH_OWNER permission will still be able to perform all operations on that projection field. This is useful for fields that should only be accessible by the system itself.

Unspecified Operation Permissions

The following statement will make the update, create and delete operations publicly available:

@permission(read: ["USER_READ"])

This is because only the read operation is specified.

Unspecified Operations

All operations that are not specified are publicly available.

Omitting the Permission Directive

Not specifying the @permission directive will result in all operations on the projection field being publicly available.

This will generate special public endpoints that work without a jwt.

Omitting the readById operation

If you do not specify the readById operation in the @permission directive, reading by id will fall back to the read operation.

The following means that the USER_READ permission can read all entries of the projection and reading by id is also allowed for the USER_READ permission:

@permission(read: ["USER_READ"])

The following will result in the USER_READ permission being able to read all entries of the projection, but reading by id will not be allowed:

@permission(read: ["USER_READ"], readById: [])

@permission

On this page