update db usage and init db files

This commit is contained in:
bob
2026-05-29 13:13:11 -05:00
parent 3d3a5c2a5e
commit 286d1366fe
10 changed files with 195 additions and 33 deletions

View File

@@ -0,0 +1,40 @@
-- ============================================================
-- CS2 Skin Tracker — drop a pre-existing skintracker_app role
-- Run ONCE as a superuser (e.g. postgres) BEFORE
-- 01_schema_and_roles.sql, to remove an older role and
-- everything it owns so the creation script starts clean.
--
-- IMPORTANT:
-- * Connect to the SAME database that contains the old
-- skintracker schema/tables. DROP OWNED only affects the
-- current database, so if the role owns objects in more
-- than one database, run this in each of them.
-- * This is DESTRUCTIVE: it drops the schema, tables, and any
-- data the role owns. Back up first if you need the data.
-- ============================================================
-- 1. (Optional) Terminate any live sessions still using the role,
-- otherwise the DROP ROLE can fail with "role is being used".
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE usename = 'skintracker_app'
AND pid <> pg_backend_pid();
-- 2. Reassign ownership of the DATABASE away from the role.
-- DROP OWNED BY does NOT cover database ownership (a database is a
-- cluster-level object), so the role must hand off the database
-- first or DROP ROLE fails with "owner of database skintracker".
-- Run this while connected as the target owner (e.g. postgres).
ALTER DATABASE skintracker OWNER TO CURRENT_USER;
-- 3. Drop everything the role owns (schema, tables, indexes, etc.)
-- and revoke any privileges granted to it, then drop the role.
-- Guarded so the script is safe to run even if the role is gone.
DO $$
BEGIN
IF EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'skintracker_app') THEN
EXECUTE 'DROP OWNED BY skintracker_app CASCADE';
EXECUTE 'DROP ROLE skintracker_app';
END IF;
END
$$;

View File

@@ -0,0 +1,40 @@
-- ============================================================
-- CS2 Skin Tracker — schema & role hardening
-- Run ONCE as a superuser (e.g. postgres), connected to the
-- skintracker database, before the app's first migration.
--
-- Replace the password placeholders before running.
-- The application/migration connection should authenticate as
-- the skintracker_app role.
-- ============================================================
-- 1. Application login role (least-privilege; not a superuser).
-- Skip the CREATE if the role already exists.
CREATE ROLE skintracker_app WITH LOGIN PASSWORD 'change-me-strong-password';
-- 2. Create the schema and make the app role its owner.
-- Because the app owns it, EF's `EnsureSchema` (CREATE SCHEMA IF
-- NOT EXISTS) becomes a no-op and the app can create/alter tables
-- here during `database update` without any rights on `public`.
CREATE SCHEMA IF NOT EXISTS skintracker AUTHORIZATION skintracker_app;
-- 3. Lock down the default `public` schema.
-- Historically every role had CREATE on public; revoke it so no
-- objects can be created there by accident. (PG15+ already removed
-- this by default, but being explicit is harmless and portable.)
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
-- 4. Make the app role use its own schema by default (so unqualified
-- object names resolve to skintracker, not public).
ALTER ROLE skintracker_app SET search_path = skintracker;
-- ------------------------------------------------------------
-- Optional: a read-only role for reporting / BI.
-- Uncomment if you need separate read-only access.
-- ------------------------------------------------------------
-- CREATE ROLE skintracker_readonly WITH LOGIN PASSWORD 'change-me-too';
-- GRANT USAGE ON SCHEMA skintracker TO skintracker_readonly;
-- GRANT SELECT ON ALL TABLES IN SCHEMA skintracker TO skintracker_readonly;
-- -- Apply automatically to tables created LATER by the app role:
-- ALTER DEFAULT PRIVILEGES FOR ROLE skintracker_app IN SCHEMA skintracker
-- GRANT SELECT ON TABLES TO skintracker_readonly;