Authorization

Access to SeviaFlow passes through separate checks. Authentication establishes who made the request; panel access controls entry to the UI; Resource authorization controls operations on a model; query scoping limits which rows appear. Configure each boundary that applies to your app.

1. Authentication and UI panel access

The UI routes use Laravel's web and auth middleware by default. Core also reads seviaflow.permissions.admin_gate when the UI checks access to its protected panel. The host must supply this callable. It receives the current user (or null) and must return a boolean.

'admin_gate' => static fn (?Authenticatable $user): bool =>
    $user instanceof User && (bool) $user->is_admin,

The default is null, and a missing gate fails closed. The UI applies the panel check on protected requests and Livewire updates; after login it checks the same gate before creating a panel session. The gate answers “may this signed-in user enter the operator panel?” It does not decide which records or operations are allowed inside the panel.

2. Optional SeviaFlow role permissions

Core's role-permission checker is controlled separately by permissions.enabled, which defaults to false. When enabled, the actor must be an appropriate user model assigned a role with an allowed row for the Resource slug and ability. This is useful for configurable operator roles, but it does not replace Laravel authentication or the UI panel gate.

3. Laravel model policies

If Laravel has a policy for the Resource's model, Core asks that policy about the requested ability and model (or record). If no policy exists, Core allows the operation after the optional role-permission check passes. This means that, with role permissions disabled and no model policy, Resource operations are allowed to an authenticated request that reaches the adapter.

Before enabling an API ResourceThe UI panel gate does not protect API routes. The API uses its own middleware (by default api and auth:sanctum), then Core's Resource authorization. Add model policies or enable and configure role permissions for sensitive data and mutations. Keep each API field and operation allowlist as small as the use case requires.

Common Resource abilities

Ability	Purpose
`viewAny`	List/index access.
`view`	Show one record.
`create`	Create records.
`update`	Update records and execute per-record actions.
`delete`	Delete records.
`restore`	Restore soft-deleted records.
`forceDelete`	Force-delete records.
`apiDocs.view`	API docs navigation/view permission metadata.

Row-level and tenant scoping

Use the Resource's query(Builder $query) method to constrain the base set of rows before search, filters, sorting and pagination. For example, a multi-tenant Resource can add the current user's tenant condition:

use Illuminate\Database\Eloquent\Builder;

// Inside the Resource class:
public static function query(Builder $query): Builder
{
    return $query->where('tenant_id', auth()->user()->tenant_id);
}

Adapt the tenant lookup and guest behavior to your app. The query scope limits which rows are returned; it does not authorize individual operations. Keep Laravel policies or SeviaFlow role permissions for view, create, update and delete checks. See Resources for the method reference.

A practical setup sequence

Keep the adapter's authentication middleware enabled and use the host application's real user provider.
Configure a UI panel gate that admits only trusted operators.
Write a Laravel policy for each sensitive model and test each operation.
For multi-tenant data, scope the Resource query and enforce tenant ownership in policies or business logic as appropriate.
Before enabling API access, configure API authentication, explicit field/operation allowlists and policy checks.

See Your First Resource for a working panel-gate example, Configuration for the exact keys and API installation for Sanctum setup.