Legge til argon2-cffi, pyotp, qrcode i requirements.txt Skrive migrasjon 012 (passord, 2FA, superadmin, org-invitasjoner) app/auth.py: sesjonsstadier, passord-hashing, TOTP-hjelpere app/routers/auth.py: passord-innlogging, 2FA-oppsett/verifisering app/email.py: 2FA-kode og invitasjons-maler app/routers/organizations.py: invitasjoner, medlemskapsstyring, superadmin-sti Frontend: login-form passord-modus + 2FA-skjermer Frontend: kontoinnstillinger + org-medlemsstyring-skjerm Ekte typesjekket frontend-build Scratch-verifisere hele auth-løpet grundig (backend) Deploy mot ekte teecup_db/containere + oppdatere .md-filer Backend og frontend er grundig scratch-verifisert — inkludert tre reelle bugs jeg fant og fikset underveis (en UUID-serialiseringsfeil i magic-link-innlogging, og to tilfeller av en uendelig 2FA-løkke der en nettopp bekreftet kode ble sjekket på nytt). Alle sikkerhetsvern testet eksplisitt: siste-eier-vern, blokkert selv-forfremmelse, admin kan ikke gi eierskap, superadmin fungerer/avvises riktig, tvungen 2FA for nye eiere, passord med spesialtegn/mellomrom, og bakoverkompatibilitet med eksisterende magic-link-flyt. Klar til utrulling mot ekte systemer: Migrasjon: 012_password_2fa_and_org_invitations.sql mot ekte teecup_db Redeploy: både teecup_api og teecup_frontend AskUserQuestion
115 lines
5.7 KiB
PL/PgSQL
115 lines
5.7 KiB
PL/PgSQL
-- =====================================================================
|
|
-- TeeCup — migrasjon 012
|
|
-- Passord (valgfritt tillegg) + 2FA (ADR-021), organisasjonsinvitasjoner
|
|
-- + superadmin (ADR-022)
|
|
-- =====================================================================
|
|
-- Kjøres etter 001-011.
|
|
-- =====================================================================
|
|
|
|
\set ON_ERROR_STOP on
|
|
|
|
-- ---------------------------------------------------------------------
|
|
-- 1. Passord (ADR-021 Beslutning A/B) -- Argon2id, ALDRI påkrevd.
|
|
-- NULL betyr "ikke satt" -- brukeren har da fortsatt kun magic-link.
|
|
-- ---------------------------------------------------------------------
|
|
ALTER TABLE app_user ADD COLUMN password_hash text;
|
|
|
|
-- ---------------------------------------------------------------------
|
|
-- 2. 2FA (ADR-021 Beslutning C/D) -- TOTP eller e-post-engangskode,
|
|
-- brukerens eget valg. totp_secret er kun satt når metoden er 'totp'.
|
|
-- ---------------------------------------------------------------------
|
|
ALTER TABLE app_user ADD COLUMN two_factor_method text
|
|
CHECK (two_factor_method IN ('totp', 'email'));
|
|
ALTER TABLE app_user ADD COLUMN totp_secret text;
|
|
ALTER TABLE app_user ADD CONSTRAINT app_user_totp_secret_requires_totp_method
|
|
CHECK (totp_secret IS NULL OR two_factor_method = 'totp');
|
|
|
|
-- Engangskoder for e-post-2FA. Samme hash-og-utløp-mønster som
|
|
-- magic_link_token (004), men knyttet til user_id (identiteten er allerede
|
|
-- bevist av primær-autentiseringen på dette tidspunktet).
|
|
CREATE TABLE two_factor_code (
|
|
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
|
|
user_id uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
code_hash text NOT NULL,
|
|
expires_at timestamptz NOT NULL,
|
|
consumed_at timestamptz,
|
|
created_at timestamptz NOT NULL DEFAULT now()
|
|
);
|
|
CREATE INDEX ON two_factor_code (user_id);
|
|
GRANT SELECT, INSERT, UPDATE, DELETE ON two_factor_code TO teecup_app;
|
|
|
|
-- ---------------------------------------------------------------------
|
|
-- 3. Superadmin (ADR-022 Beslutning D) -- KUN manuelt DB-tildelt.
|
|
-- Bevisst INGEN API-endepunkt setter/gir dette flagget -- se ADR-022
|
|
-- for hvorfor et selvbetjent "bli superadmin"-endepunkt ville vært
|
|
-- selve sikkerhetshullet.
|
|
-- ---------------------------------------------------------------------
|
|
ALTER TABLE app_user ADD COLUMN is_super_admin boolean NOT NULL DEFAULT false;
|
|
|
|
-- ---------------------------------------------------------------------
|
|
-- 4. Organisasjonsinvitasjoner (ADR-022 Beslutning B) -- e-post +
|
|
-- tiltenkt rolle. INGEN egen klikkbar token/lenke -- aksept skjer
|
|
-- automatisk ved neste innlogging med matchende e-post (samme mønster
|
|
-- som spiller-e-post-kobling, ADR-017 Beslutning B), ikke et eget
|
|
-- verifiseringstrinn.
|
|
-- ---------------------------------------------------------------------
|
|
CREATE TABLE organization_invitation (
|
|
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
|
|
organization_id uuid NOT NULL REFERENCES organization(id) ON DELETE CASCADE,
|
|
email citext NOT NULL,
|
|
role text NOT NULL CHECK (role IN ('owner', 'admin', 'member')),
|
|
invited_by uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
expires_at timestamptz NOT NULL,
|
|
consumed_at timestamptz,
|
|
created_at timestamptz NOT NULL DEFAULT now()
|
|
);
|
|
-- Kun én AKTIV (uforbrukt) invitasjon per e-post per organisasjon.
|
|
CREATE UNIQUE INDEX organization_invitation_active_unique
|
|
ON organization_invitation (organization_id, email) WHERE consumed_at IS NULL;
|
|
CREATE INDEX ON organization_invitation (email);
|
|
|
|
ALTER TABLE organization_invitation ENABLE ROW LEVEL SECURITY;
|
|
ALTER TABLE organization_invitation FORCE ROW LEVEL SECURITY;
|
|
CREATE POLICY org_isolation ON organization_invitation
|
|
USING (organization_id = app_current_org())
|
|
WITH CHECK (organization_id = app_current_org());
|
|
|
|
GRANT SELECT, INSERT, UPDATE, DELETE ON organization_invitation TO teecup_app;
|
|
|
|
-- ---------------------------------------------------------------------
|
|
-- 5. accept_pending_invitations_by_email() -- femte SECURITY DEFINER-bro
|
|
-- i prosjektet (etter public_tournament_org 007, link_player_by_email
|
|
-- 008, public_org_by_slug 009, public_tournament_by_code 011). Kjøres
|
|
-- på HVER innlogging (magic-link OG passord), samme idempotente,
|
|
-- "berører kun uforbrukte/gyldige rader"-mønster som
|
|
-- link_player_by_email -- gjentatte kall er en no-op.
|
|
--
|
|
-- organization_membership har INGEN RLS (se 001 -- "håndteres av
|
|
-- auth-laget"), så selve INSERT-en trenger ikke SECURITY DEFINER for
|
|
-- å krysse org-grenser -- men organization_invitation (som denne
|
|
-- leser fra) HAR RLS, og en bruker som blir invitert er per
|
|
-- definisjon IKKE medlem av org-en ennå (kan derfor ikke ha
|
|
-- app.current_org satt til den). SECURITY DEFINER løser dette
|
|
-- kontekst-problemet på nøyaktig samme måte som de fire tidligere
|
|
-- broene.
|
|
-- ---------------------------------------------------------------------
|
|
CREATE FUNCTION accept_pending_invitations_by_email(p_user_id uuid, p_email text)
|
|
RETURNS void
|
|
LANGUAGE sql
|
|
SECURITY DEFINER
|
|
SET search_path = public
|
|
AS $$
|
|
WITH accepted AS (
|
|
UPDATE organization_invitation
|
|
SET consumed_at = now()
|
|
WHERE consumed_at IS NULL
|
|
AND expires_at > now()
|
|
AND lower(email) = lower(p_email)
|
|
RETURNING organization_id, role
|
|
)
|
|
INSERT INTO organization_membership (organization_id, user_id, role)
|
|
SELECT organization_id, p_user_id, role FROM accepted
|
|
ON CONFLICT (organization_id, user_id) DO NOTHING;
|
|
$$;
|
|
|
|
GRANT EXECUTE ON FUNCTION accept_pending_invitations_by_email(uuid, text) TO teecup_app;
|