Snehil_Shah@supasession
SupaSession
Advanced session management for Supabase
Limit and restrict user sessions in Supabase Auth, without the Pro Plan.
This is supposed to be an alternative to Supabase Pro's single-session-per-user feature, but more flexible and for the brokies.
Prerequisites
- Supabase with Auth enabled
Installation
Install via database.dev:
SELECT dbdev.install('Snehil_Shah@supasession');
To learn how to install dbdev
and published TLE extensions, read here.
[!WARNING] This extension is installed in the
supasession
schema and can potentially cause namespace collisions if you already had one before.
Usage
CREATE EXTENSION "Snehil_Shah@supasession";
Quick start
-- Enable session limits:
SELECT supasession.enable();
-- Set limits:
SELECT supasession.set_config(max_sessions := 3);
<!-- <docs> -->
Types
supasession.enforcement_strategy
Represents the strategy for enforcing session limits.
- dequeue - Destroys the oldest session when the limit is reached
- reject - Rejects any new sessions when the limit is reached
Tables
supasession.config
Extension configuration.
- enabled (
BOOLEAN
) - Whether session limiting is enabled (Default:FALSE
) - max_sessions (
INTEGER
): Maximum number of active sessions allowed per user (Default:1
) - strategy (
supasession.enforcement_strategy
): Enforcement strategy when the session limit is reached (Default:dequeue
)
Functions
These functions provide a convenient layer on top of supasession.config
to manage extension configuration.
Alternatively, you can always directly query/update the supasession.config
table.
supasession.enable()
Enables session limits enforcement.
SELECT supasession.enable();
Returns:
VOID
supasession.disable()
Disables session limits enforcement.
SELECT supasession.disable();
Returns:
VOID
supasession.set_config( [enabled BOOLEAN], [max_sessions INTEGER], [strategy supasession.enforcement_strategy] )
Updates extension configuration.
SELECT supasession.set_config(max_sessions := 5);
SELECT supasession.set_config(enabled := FALSE, strategy := 'reject');
Parameters:
- enabled (
BOOLEAN
, optional) - Whether session limiting is enabled - max_sessions (
INTEGER
, optional) - Maximum number of active sessions allowed per user - strategy (
supasession.enforcement_strategy
, optional) - Enforcement strategy when the session limit is reached
Returns:
supasession.config
- Updated configuration
supasession.get_config()
Retrieves extension configuration.
SELECT supasession.get_config();
Returns:
supasession.config
- Current configuration
Auth helpers
Helper functions to work with sessions within RPCs.
supasession.sid()
Returns the session ID from the JWT of the current request. (Analogous to auth.uid()
)
SELECT supasession.sid() AS session_id;
Returns:
UUID|NULL
- The session ID (auth.sessions.id
), orNULL
if not available
Caveats
Some things to be aware of:
-
This extension intercepts the session-creation flow and not token-refreshes. This means once you enable it or change any configuration, they will only be enforced for a user after that user signs in again. Until then, all existing sessions of said user enjoy their time even if they don't meet the set limits.
To avoid this, it's recommended to destroy all existing sessions and force all users to sign-in again fresh, if you wish to enforce the updated extension configuration right away. To do this: run
DELETE FROM auth.sessions
. Don't be scared of the warnings, it only deletes temporary session data to invalidate all existing user sessions and make them sign-in again. -
Just like Supabase's single-session-per-user, invalid users won't be logged out immediately when a new sign in occurs. A session stays active throughout the lifetime of the JWT access token and can only be invalidated once it expires. You can reduce the JWT expiry time to go against this, but Supabase doesn't recommend going below 5 minutes. To change the JWT expiration time, go to Project Settings > JWT Keys in your project dashboard, or set it under
auth.jwt_expiry
inconfig.toml
for local instances. -
This extension can overestimate the number of valid sessions in certain cases where sessions are invalid due to Low AALs or timeouts. This is due to such configurations (mostly Pro features) being defined in the API layer which this extension doesn't have access to. Such sessions are still cleaned up by Supabase eventually, but during that window, blocking enforcement strategies like
reject
can cause your app to reject valid login requests.TL;DR: If you are using Pro Auth features like Time-boxes and inactivity timeouts, it's recommended to use non-blocking enforcement strategies like
dequeue
. -
As all strategies are enforced at the database level, you won't see the prettiest of error messages for blocking strategies like
reject
, requiring special error handling by the client.
Install
- Install the
dbdev
package manager - Install the package:
select dbdev.install('Snehil_Shah@supasession');
create extension "Snehil_Shah@supasession"
version '0.1.2';
Downloads
- 5 all time downloads
- 5 downloads in the last 30 days
- 5 downloads in the last 90 days
- 5 downloads in the last 180 days