Raw session tokens stay out of storage
The browser carries an opaque value. The server combines digest comparison, absolute expiry, idle expiry, rotation and revocation.
Keep the boundaries visible
The library centralizes security decisions without taking over product rules.
You decide who may change each resource. GuildGate makes sure the same checks run in the same order for every protected write.
Protected writes share one pipeline
Input, resource, origin, session, CSRF, user permission, bot permission, idempotency and resource locks do not drift across route files.
Your application keeps control of storage
Implement the store contracts with PostgreSQL, MySQL, MongoDB, SQLite, Redis, an existing ORM or a private storage service.
Realtime subscriptions require authorization
WebSocket, Socket.IO and SSE connections apply session, guild access, sequencing, replay and backpressure rules.
First protected action
Keep resource lookup, authorization and persistence in one definition.
An action definition does more than wrap an HTTP route. It can connect idempotency, concurrent-write protection, transaction hooks, cache invalidation and audit events to the same lifecycle.
Read the action layerconst updateSettings = gate.action({
name: "guild.settings.update",
parse: parseSettings,
resource: ({ guildId }) => ({
type: "guild",
id: guildId,
}),
authorize: canManageGuild,
transaction: { required: true, isolation: "serializable" },
execute: saveSettings,
invalidate: ({ guildId }) => [`guild:${guildId}:settings`],
});Try the rules
See which check stops a request before changing a real setting.
The verification console does not open a shell or send network requests. It evaluates documented origin, session, store, permission, rate-limit and realtime examples.
This console does not open a shell or send your input to a server. It checks GuildGate’s documented decision rules in your browser.
Console ready.
Run `help` or choose one of the examples below.