Files

T

Paul Nothaft 7f7d38a57f fix(oidc): security + robustness hardening from codex review rounds 1-2

Round 1:
- bind SSO identities to (external_issuer, external_subject): OIDC only
  guarantees sub uniqueness within an issuer, so a sub-only lookup let a
  newly configured IdP's user inherit an old IdP's admin account on
  subject collision; migration 162 gains external_issuer + composite
  unique index (unmerged migration, edited in place)
- fetch UserInfo (with sub cross-check) when the ID token carries no
  email — spec-compliant providers may serve email/profile claims only
  there; ID-token claims win on merge
- allowlist /admin/sso/login + /callback in maintenance mode, or
  SSO-only (JIT) admins are locked out exactly when they need in
- strip reserved keys (oidc_client_secret, setup_token) from BOTH
  generic settings reads (GET / and GET /:type)

Round 2:
- redirect_uri prefers API_URL (the API's public origin — where the
  state cookie lives); final redirects absolute to the frontend base;
  login button builds its URL via buildResourceUrl — split-origin
  deployments (absolute VITE_API_URL) work end to end
- PUT /sso validates the MERGED resulting state (partial update cannot
  blank issuer/client while enabled=true survives; enabling requires a
  derivable redirect URI)
- openid scope forced into oidc_scopes on save
- discovery-cache key includes a secret fingerprint (multi-worker
  secret rotation)
- email→admin linking claims the row atomically (conditional update on
  external_subject IS NULL) — concurrent first-time callbacks with the
  same verified email but different subjects can't both authenticate

Tests: mock IdP gains userinfo endpoint + email-via-userinfo-only mode;
new cases pin the userinfo merge and issuer-collision non-inheritance;
redirect assertions updated for absolute URLs. 13/13.

2026-07-16 09:41:48 +02:00

core

fix(oidc): security + robustness hardening from codex review rounds 1-2

2026-07-16 09:41:48 +02:00

legacy

fix: prevent database migration restart failures

2026-01-15 15:43:13 +01:00

041_add_logo_customization_settings.js

feat: implement gallery logo customization (Issue #17 )

2025-09-05 14:56:09 +02:00

helpers.js

Initial commit - Project start (July 17, 2025)

2025-07-24 16:57:07 +02:00

README.md

feat: pre-generate watermarks for instant lightbox loading

2026-01-15 21:00:10 +01:00

run-migrations-safe.js

feat(install): skip legacy chain when modern bootstrap fingerprint detected (#530 )

2026-05-19 22:48:54 +02:00

run-migrations.js

fix: prevent database migration restart failures

2026-01-15 15:43:13 +01:00

README.md

Database Migrations

This directory contains database migrations for the PicPeak photo sharing platform.

Directory Structure

`/core`

Essential migrations that are always run for new deployments. These include:

init.js - Initial database schema creation
Backup service tables (029-035)
Gallery feedback tables (033)
Pre-generated watermarks (061)

`/legacy`

Migrations needed only when upgrading from older versions. New deployments can skip these as the core schema already includes all necessary tables and columns.

For New Deployments

If you're deploying this application for the first time:

The initializeDatabase() function in src/database/db.js will create all necessary tables
Only migrations in the /core directory will be run
This ensures a clean, optimized database schema

For Existing Deployments

If you're upgrading from an older version:

All migrations (both core and legacy) will be run in sequence
The migration system tracks which migrations have been applied
Only new migrations will be executed

Running Migrations

# Development
npm run migrate

# Production
npm run migrate:prod

Note on Duplicate Migration Numbers

The legacy directory contains renamed duplicates:

014_add_host_name_to_events_duplicate.js (was duplicate of 014)
027_add_rate_limit_settings_duplicate.js (was duplicate of 027)

These have been renamed to avoid conflicts while preserving the migration history.