← Addonium

7. Tokenized URLs

The "url-token" auth method is the recommended default for Locked HTTP addons because it requires zero client-side auth logic - the base URL already carries everything.

https://api.example.com/t/eyJhbGciOiJIUzI1NiJ9.eyJ1IjoiOTkyIn0.9f3a...
                            └──────────────── token segment ────────────┘
GET  /t/{token}/manifest.json
GET  /t/{token}/search?q=...
GET  /t/{token}/stream/abc123
  • The host treats everything after the domain as an opaque prefix - it never parses or strips the token, it just always prepends the full baseUrl it was given.
  • Tokens SHOULD be self-contained and verifiable server-side (e.g. a signed JWT or HMAC'd blob) so the addon's server needs no session store to validate them - consistent with "no Cloudflare Workers, no mandatory backend."
  • If the addon optionally stores per-user data (§11), the same token segment doubles as the encrypted user-correlation key - see §11.2.
  • Rotating/revoking access is just re-issuing a new token segment; old URLs stop resolving whenever the author's server chooses to reject them.

7.1 Compiled-module equivalent

For compiled modules, the analogous artifact is a small key file (.aiumkey) or key string, distributed separately from the module script:

my-addon.aium        ← the module code (safe to share publicly)
my-addon.aiumkey     ← per-user key (keep private; unlocks the module)

The module refuses to produce real results (or refuses to execute at all, depending on the author's chosen strictness - see §9.4) without a valid key supplied by the host at load time.