Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.withsutro.com/llms.txt

Use this file to discover all available pages before exploring further.

SLang has a built-in security model based on Subjects, Permissions, and Roles.

​
Defining permissions

Permissions are defined on relationships between a resource (e.g., Clinic) and a user link (e.g., Membership). 
permissions Clinic -> Membership
  "patients:read"
  "patients:write"
  "clinic:admin"
This tells the system that specific roles defined in the Membership entity will dictate access to Clinic resources.

​
Enforcing auth

The auth block in a Trigger acts as a firewall. Logic is not executed unless the condition passes. If a trigger omits the auth block entirely, the route is public and can be called without authentication.

​
Permission checks

Check if the authenticated user (@subject) has a specific permission. 
trigger ListPatients on HttpRequest
  endpoint GET /patients
  auth
    @subject can "patients:read"

​
Role checks

You can also check for specific roles directly, though permissions are preferred for flexibility. 
auth
  @subject is "admin"

​
Complex logic

Auth rules can be combined with and / or. 
auth
  (@subject can "patients:write") or (@subject is "superuser")

​
The @subject

The keyword @subject refers to the currently authenticated user (derived from the Bearer token or session). It is available in:
  1. Triggers: For auth checks.
  2. Actions: To assign ownership (e.g., Owner := @subject).
Use @subject.entity when you need the authenticated subject’s data row: 
action CurrentUser(): User
  body
    return @subject.entity