@kontrolia/db 2.1.1 → 2.1.3

package/migrations/0036_application_oauth_client_link.sql

@@ -0,0 +1,20 @@
+-- Lets an application's own row remember which GoTrue OAuth 2.1 client it
+-- registered, so admin-panel can manage OAuth-client credentials from
+-- inside that application's row instead of a separate, disconnected
+-- top-level "Clientes OAuth" screen. No real FK is possible — GoTrue's
+-- OAuth clients live entirely outside this schema, reachable only via its
+-- own admin HTTP API (see apps/auth-server/app/api/oauth-clients/route.ts),
+-- not a Postgres table this database has any relationship to. This is
+-- purely a pointer, populated by the application layer after a successful
+-- POST to that route.
+--
+-- An old day-one migration comment (0003_applications_and_permissions.sql:
+-- "oauth_clients (v2) attach real OAuth2 credentials to a row here") shows
+-- this link was the original intended design; it was never implemented and
+-- the two concepts drifted apart into fully separate admin-panel pages.
+-- This finally closes that gap.
+
+alter table kontrolia_auth.applications add column oauth_client_id text;
+
+comment on column kontrolia_auth.applications.oauth_client_id is
+  'GoTrue OAuth 2.1 client_id registered for this application, if any — set by admin-panel after POST /api/oauth-clients succeeds. Not a foreign key: GoTrue''s own oauth_clients table lives outside kontrolia_auth, reachable only via its admin API.';

package/migrations/0037_grant_oauth_client_id_select.sql

@@ -0,0 +1,19 @@
+-- Migration 0036 added applications.oauth_client_id but forgot the
+-- column-level grant migration 0032 made mandatory for any new column on
+-- this table: 0032 revoked the old blanket `grant select on all tables to
+-- authenticated` and replaced it with an explicit per-column list, so a
+-- column added later without its own grant is invisible to `authenticated`
+-- — worse than invisible, actually: PostgREST's single SELECT statement
+-- fails outright with "permission denied for table applications" the
+-- moment oauth_client_id is included alongside the columns that ARE
+-- granted, taking the whole query down with it. Live-reproduced against
+-- production: apps/admin-panel's applications page select list includes
+-- oauth_client_id unconditionally, so every authenticated user's query
+-- failed and the entire "Aplicaciones" list rendered empty since 0036
+-- shipped — not a caching or migration-timing issue, a missing grant.
+--
+-- Not sensitive like api_key_hash (a GoTrue client_id, not a secret), so
+-- it belongs in the same broadly-readable column set as
+-- owner_organization_id/homepage_url/etc., not restricted to service_role.
+
+grant select (oauth_client_id) on kontrolia_auth.applications to authenticated;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kontrolia/db",
-  "version": "2.1.1",
+  "version": "2.1.3",
   "license": "MIT",
   "description": "KontrolIA Auth database layer: SQL migrations for the `kontrolia` schema (organizations, RBAC, Custom Access Token Hook) and a connection-string-agnostic migration runner.",
   "keywords": [