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.

Generated apps turn SLang security declarations into runtime authentication and authorization behavior.

​
Request Flow

When a request reaches a generated app:
  1. The runtime extracts credentials from the request.
  2. It validates the credentials and establishes a subject.
  3. It resolves principals, roles, groups, and permissions for that subject.
  4. It exposes the result to SLang as @subject.
  5. It evaluates the trigger auth block before running the action.
If credentials are missing where authentication is required, the request fails with 401. If the subject is authenticated but does not satisfy the auth rule, the request fails with 403.

​
Subject Resolution

The generated app can resolve @subject.entity only when the token subject matches a SLang entity marked with subject and identity. 
entity User
  subject
  identity email
  fields
    email: EMAIL
    displayName: TEXT?

action CurrentUser(): User
  body
    return @subject.entity

action UpdateDisplayName(displayName?: TEXT): User
  body
    user := @subject.entity
    update user {
      displayName := displayName
    }
    return user

trigger CurrentUser on HttpRequest
  endpoint GET /me
  auth
    @subject is @defined

trigger UpdateDisplayName on HttpRequest
  endpoint PATCH /me
  arguments
    displayName := @request.body.displayName
  auth
    @subject is @defined
The identity email declaration tells the generated app which user field is used for registration and login. The runtime also tracks the internal @id, which lets @subject.entity fetch the persisted user row.

​
Principals, Roles, and Permissions

Principals are security facts about a subject. Roles and permissions are derived from the model relationships declared in SLang:
  • group @id marks an entity whose instances can scope permissions.
  • role roleField marks the enum field that carries a role.
  • permissions Subject->relationPath->roleValue grants permission strings to that role.
At request time, generated apps use those declarations to build @subject.roles and principal permissions. Trigger auth checks such as @subject can "project:read" in Organization(@request.path.organizationId) are evaluated from that runtime subject context.

​
Generated Auth Endpoints

Subject declarations enable generated auth endpoints:
  • POST /register
  • POST /login
  • POST /refresh
  • GET /.well-known/jwks.json
Registration and login use the identity field declared in SLang. For identity email, clients send the user’s email as the identity value.

​
Practical Guidance

Keep auth checks at the trigger boundary for coarse access control, and keep ownership checks inside actions for record-level safety. For example, a trigger can require @subject is @defined, while the action uses single Document where @id == documentId and owner == @subject.entity.