Files

T

Poyraz Avsever 950522d467 feat: Implement first admin setup guard to lock registration after initial account creation

- Updated the registration flow to check if the first admin account has been created, preventing further public registrations.
- Introduced `is_first_admin_setup_available` function to determine registration availability.
- Modified the `/register` and `/login` pages to redirect based on the setup state.
- Enhanced the user creation process to handle internal admin accounts correctly.
- Added migration script to enforce the new registration rules in the database.
- Refactored chat API to improve message handling and context building.
- Updated dashboard and settings components for better state management.
- Improved error handling and user feedback across various components.

2026-06-08 16:22:26 +03:00

1.6 KiB

Raw Blame History

0009 - Lock Registration After First Admin

SQL file:

supabase/migrations/0009_lock_registration_after_first_admin.sql

Purpose

Adds the first-time setup guard for self-hosted installations.

The /register page is only available while the system has no profile record. After the first account creates a profile, public registration is closed.

Changes

Adds public.is_first_admin_setup_available().
Grants the function to anon and authenticated roles so the app can check setup state safely without bypassing RLS manually.
Replaces public.handle_new_user() so direct public Supabase Auth signup attempts are also rejected after the first profile exists.
Allows service-role/admin-created users when raw_app_meta_data.internal_created is true, so future invite/client-portal flows can still create accounts intentionally.

Behavior

Fresh install has no public.profiles rows.
/register stays open.
The first signup creates an auth user and the trigger creates the first profile.
The setup function starts returning false.
/register redirects to /login.
Further public signup attempts fail at the database trigger level.
Admin-created internal users can still be allowed by service-role flows that set app_metadata.internal_created = true.

Notes

This is intended for the MVP single-admin self-host model.
If multi-user, client portal accounts, invites, or team members are re-enabled later, keep them behind service-role/admin-created flows instead of public signup.
Do not add this SQL file to query-log.md until it has actually been run in the target Supabase environment.

1.6 KiB Raw Blame History