School Scoping and Authorization - Kralis Docs

Kralis is a multi-school platform. The authenticated user’s school is the tenant boundary for normal application work.

Client responsibilities

Do	Do not
Use the school returned during authentication	Ask the user to type an arbitrary school identifier
Use opaque IDs returned by the API	Guess IDs or build authorization from URL values
Hide actions unavailable to the current role	Assume hiding a button replaces server authorization
Handle permission errors as expected outcomes	Retry a forbidden operation with another school ID
Refresh context after role or school changes	Cache authorization decisions indefinitely

Roles and relationships

Access may depend on more than a broad role. A teacher’s classes or subjects, a student’s class and section, an LMS enrollment, a CBT session’s eligibility, or a Classroom access grant can narrow what the user may see and do.

IDs

Use IDs from authenticated responses for follow-up GraphQL operations. Do not derive authorization from a school acronym, name, slug, or a copied URL; the API applies the signed-in user’s school and role.

Diagnosing missing data

A globally privileged-looking account is not permission to mix schools in a public client. Render and operate within the school context authorized by the API.

⌘I