rally_runtime/auth

Auth types and helpers.

Page modules use AuthPolicy values with pub const page_auth, and SSR load functions return LoadResult values when auth is enabled. App-specific identity functions such as resolve, is_authenticated, and authorize are still defined per namespace by the app.

Rally also provides helpers for hashing and verifying stored secrets, plus short login-code helpers for passwordless sign-in flows.

Types

AuthPolicy

</>

Per-page auth policy, declared as pub const page_auth in page modules. Required: the user must be authenticated to view the page. Optional: identity is resolved if available, but the page loads either way.

pub type AuthPolicy {
  Required
  Optional
}

Constructors

```
Required
```
```
Optional
```

</>

A cookie to set or clear in the SSR response.

pub type Cookie {
  SetCookie(name: String, value: String, max_age: Int)
  ClearCookie(name: String)
}

Constructors

SetCookie(name: String, value: String, max_age: Int)

```
ClearCookie(name: String)
```

HashError

</>

Hashing can fail only if the Erlang crypto app is unavailable or broken.

pub type HashError {
  CryptoUnavailable
}

Constructors

```
CryptoUnavailable
```

LoadResult

</>

Return type for auth-enabled load functions. Page: render the page with data and optionally set/clear cookies. Redirect: send the user elsewhere (e.g., after login or permission failure).

pub type LoadResult(data) {
  Page(data: data, cookies: List(Cookie))
  Redirect(url: String, cookies: List(Cookie))
}

Constructors

```
Page(data: data, cookies: List(Cookie))
```

Redirect(url: String, cookies: List(Cookie))

Values

generate_login_code

</>

pub fn generate_login_code() -> String

Generate a short, human-friendly login code.

These codes are meant for short-lived login flows, not long-lived session tokens or API tokens.

hash

</>

pub fn hash(secret secret: String) -> String

Hash an auth secret for storage.

This is intended for secrets that will be checked later, such as passwords or other submitted credentials. It uses PBKDF2-SHA256 with a fresh salt and stores the algorithm, version, iteration count, salt, and hash together.

Panics only if the Erlang crypto app is unavailable. Application code that wants to handle that case explicitly should use try_hash instead.

hash_login_code

</>

pub fn hash_login_code(
  scope scope: String,
  code code: String,
  secret_key secret_key: String,
) -> String

Hash a scoped login code for storage with an app secret.

The scope is usually an email address or other lookup value. Rally normalizes the scope and code before hashing. The secret key should be a stable app secret that is not stored in the database.

Login codes are short, so this uses HMAC-SHA256 instead of a bare fast hash. A leaked database cannot brute-force stored codes without the app secret.

try_hash

</>

pub fn try_hash(
  secret secret: String,
) -> Result(String, HashError)

Hash an auth secret for storage, returning an error rather than panicking. Use this when the caller needs to log or react to a hashing failure.

try_hash_login_code

</>

pub fn try_hash_login_code(
  scope scope: String,
  code code: String,
  secret_key secret_key: String,
) -> Result(String, HashError)

Hash a scoped login code, returning an error shape compatible with try_hash. HMAC hashing does not normally fail.

verify

</>

pub fn verify(
  stored stored: String,
  secret secret: String,
) -> Bool

Check a submitted auth secret against a stored hash.

verify_login_code

</>

pub fn verify_login_code(
  stored stored: String,
  scope scope: String,
  code code: String,
  secret_key secret_key: String,
) -> Bool

Check a submitted login code against a stored hash.