Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/exegia/corpora-py/llms.txt

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

The exegia.auth module provides application-level authentication on top of Supabase Auth. It handles sign-in and sign-up flows and always checks whether a matching public.users record exists before returning a result — meaning a successful sign-in requires both a valid Supabase auth identity and a provisioned application profile.

Architecture

Context Fabric splits authentication into two layers that work together: exegia.supabase — low-level layer
  • client.py creates a single synchronous Supabase client using the service-role key and the SUPABASE_API_URL constant (constructed from PROJECT_REF). Because the service-role key bypasses Row Level Security, all database operations in this layer run with elevated permissions regardless of the calling user’s session.
  • authentication.py provides typed wrappers around supabase.auth.* methods, translating raw credentials into structured AuthResponse, AuthOtpResponse, and OAuthResponse objects from supabase_auth.
exegia.auth — high-level layer
  • After any authentication call, this layer checks for a matching public.users record keyed by auth.users.id.
  • On success, it returns a SignInResult or SignUpResult dataclass carrying a CurrentUser that joins the auth identity with the application profile.
  • On failure (authenticated but no profile), it signals needs_signup so the caller can route the user to registration.

Supported Flows

FlowModuleWhen to use
Email OTP (magic link)exegia.auth.signinPasswordless login via email
OIDC ID token (Apple/Google)exegia.auth.signinSocial login with ID token
Anonymous sessionexegia.auth.signupGuest access before registration
Profile registrationexegia.auth.signupCreate public.users record

Result Types

All sign-in functions return a SignInResult. The sign_up() function returns a SignUpResult. Both are frozen dataclasses. SignInResult
ok
bool
True when the user is fully authenticated and has a public.users record.
current_user
CurrentUser | None
The combined auth identity and application profile. Set only when ok is True.
session
Session | None
The Supabase session carrying access and refresh tokens. Present on success and also on the needs_signup path, so registration can be completed without re-authenticating.
message
str | None
A user-facing message, populated on non-ok paths.
needs_signup
bool
True when the user authenticated successfully but has no public.users record yet. Defaults to False.
SignUpResult
ok
bool
True if a new public.users record was created for the user.
current_user
CurrentUser | None
The combined auth identity and profile. Set on success and on the already_registered path.
session
Session | None
The Supabase session. Populated when the anonymous flow started a new session.
message
str | None
A user-facing message, populated on non-ok paths.
already_registered
bool
True when the user already has a public.users record, so no new record was created. Defaults to False.

CurrentUser Dataclass

CurrentUser is the unified view of a signed-in user. It is a frozen dataclass with two fields that wrap the auth.users identity (a supabase_auth.User) and the public.users profile row, plus a set of convenience properties. Dataclass fields
FieldTypeDescription
auth_userUserThe Supabase Auth user object (auth.users row)
profiledict[str, Any] | NoneThe public.users record, or None when no profile exists yet
Properties
PropertyTypeDescription
idstrAuth user UUID — also the public.users primary key
emailstr | NoneUser email from the auth identity
is_anonymousboolWhether the user is an unlinked anonymous session
is_permanentboolWhether the account is fully registered (not anonymous)
has_profileboolWhether a public.users record was found
providerslist[str]List of linked OAuth provider identifiers, e.g. ["google"]
Call has_provider(provider: str) -> bool to check whether a specific provider is already linked to the user.

Configuration Required

The Supabase client is created at import time using two constants resolved from environment variables. Both must be set before importing any exegia.auth or exegia.supabase module:
  • PROJECT_REF — your Supabase project reference, used to construct SUPABASE_API_URL as https://supabase_kong_{PROJECT_REF}.orb.local
  • SUPABASE_SECRET_KEY — service-role key that bypasses RLS
See Environment Variables for the full list and setup instructions.

Sign In

Email OTP and Apple/Google OIDC flows that return a SignInResult.

Sign Up

Profile registration, anonymous sessions, and identity linking.

Build docs developers (and LLMs) love