@plutocms/supabase 0.7.1 → 0.7.2

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [0.7.2](https://github.com/plutocms/supabase/compare/v0.7.1...v0.7.2) (2026-09-13)
+
+
+### Bug Fixes
+
+* **permissions:** make requireAdmin safe on a zero-migration database ([#58](https://github.com/plutocms/supabase/issues/58)) ([a83f6d0](https://github.com/plutocms/supabase/commit/a83f6d0bfa3ae150df5b90a06fcd29fe437ad9b7))
+
 ## [0.7.1](https://github.com/plutocms/supabase/compare/v0.7.0...v0.7.1) (2026-09-13)
 
 

package/app/pages/admin/migrations.vue

@@ -30,6 +30,13 @@ const connectionForm = ref({
 })
 
 const isRunning = ref(false)
+// True only while waitForServerAndRefresh is polling through a dev-server
+// restart. useMigrations().status reads as null on every failed poll in
+// that window (see its own doc comment), which would otherwise leave the
+// page blank below the title — the toasts alone are easy to miss. The
+// template shows a persistent banner instead, keyed on this flag, so the
+// page always explains what is happening instead of going quiet.
+const isReconnecting = ref(false)
 const lastRun = ref<Awaited<ReturnType<typeof runMigrations>> | null>(null)
 // Kept only in this page's own memory, only to show the manual .env step if
 // persisting fails — see EnvPersistWarning.vue. Never sent anywhere new.
@@ -118,8 +125,12 @@ async function applyMigrations(useForm: boolean) {
         color: 'info',
       })
 
+      isReconnecting.value = true
+
       const recovered = await waitForServerAndRefresh()
 
+      isReconnecting.value = false
+
       toast.add(
         recovered
           ? {
@@ -163,7 +174,19 @@ async function applyMigrations(useForm: boolean) {
   <AdminView>
     <h1 class="text-3xl font-bold lg:text-4xl">Migrations</h1>
 
-    <div v-if="fetchStatus === 'pending'" class="flex items-center gap-x-2">
+    <UAlert
+      v-if="isReconnecting"
+      color="info"
+      variant="outline"
+      icon="lucide:refresh-cw"
+      title="Dev server restarting"
+      description="Saving a new connection string restarts the dev server. Reconnecting — this page will update on its own once it's back."
+    />
+
+    <div
+      v-else-if="fetchStatus === 'pending'"
+      class="flex items-center gap-x-2"
+    >
       <Icon name="svg-spinners:ring-resize" />
       <span>Loading migration status…</span>
     </div>
@@ -340,5 +363,25 @@ async function applyMigrations(useForm: boolean) {
         </div>
       </UCard>
     </template>
+
+    <UAlert
+      v-else
+      color="error"
+      variant="outline"
+      icon="lucide:circle-x"
+      title="Could not load migration status"
+      description="This isn't the dev-server-restart case above — something else went wrong reading migration status. Check the server console, then try again."
+    >
+      <template #actions>
+        <UButton
+          color="error"
+          variant="outline"
+          icon="lucide:refresh-cw"
+          @click="refresh()"
+        >
+          Retry
+        </UButton>
+      </template>
+    </UAlert>
   </AdminView>
 </template>

package/app/pages/admin.vue

@@ -8,19 +8,11 @@ const route = useRoute()
 const { isLoggedIn, logout, allowedUnauthenticatedPaths } = await useAuth()
 const toast = useToast()
 
-const { load: loadPermissions, clear: clearPermissions } = usePlutoPermissions()
-
-watch(
-  isLoggedIn,
-  (loggedIn) => {
-    if (loggedIn) {
-      loadPermissions()
-    } else {
-      clearPermissions()
-    }
-  },
-  { immediate: true }
-)
+// Loading/clearing permissions on login/logout lives in
+// app/plugins/pluto-permissions-sync.ts now, not here — that plugin runs
+// on every page, not just this one, so a signed-in admin browsing a public
+// page directly (no prior visit to /admin/** this session) still gets
+// their capabilities loaded.
 
 const visibility = useDocumentVisibility()
 

package/app/plugins/pluto-permissions-sync.ts

@@ -0,0 +1,38 @@
+/**
+ * Loads (or clears) the current user's capabilities whenever their session
+ * appears or disappears — app-wide, not page-scoped.
+ *
+ * This used to live as a `watch` inside `app/pages/admin.vue`. That only
+ * ran while `admin.vue` was the mounted page, so a signed-in admin loading
+ * a public page directly (a fresh navigation or a page reload, with no
+ * earlier visit to `/admin/**` in the same app instance) never triggered a
+ * load at all — `usePlutoPermissions().granted` stayed empty, and every
+ * `can()` check for that admin read as `false` on that page, even though
+ * the same admin's capability-gated UI worked correctly inside `/admin/**`.
+ * `NavbarAdminActions.vue`'s "Edit product" quick-link (shown while
+ * viewing a live `/product/**` page) is exactly the kind of capability-
+ * gated UI that lives outside `/admin/**` by design, so it needs this to
+ * fire on every page, not just admin ones.
+ *
+ * `useSupabaseSession()` (not `useAuth()`) on purpose: it is the same
+ * primitive `useAuth()`'s own `isLoggedIn` is built from
+ * (`computed(() => !!supabaseSession.value)`), and it is genuinely
+ * app-wide reactive state already (managed by `@nuxtjs/supabase`'s own
+ * plugin), so reading it directly here needs no extra composable surface.
+ */
+export default defineNuxtPlugin(() => {
+  const session = useSupabaseSession()
+  const { load, clear } = usePlutoPermissions()
+
+  watch(
+    session,
+    (current) => {
+      if (current) {
+        load()
+      } else {
+        clear()
+      }
+    },
+    { immediate: true }
+  )
+})

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@plutocms/supabase",
   "type": "module",
-  "version": "0.7.1",
+  "version": "0.7.2",
   "trustedDependencies": [
     "@parcel/watcher",
     "@plutocms/pluto",

package/server/utils/admin-guard.ts

@@ -4,25 +4,42 @@ import { serverSupabaseClient, serverSupabaseUser } from '#supabase/server'
 /**
  * Guards a server route so only an admin can call it.
  *
- * Calls `public.is_admin()` directly — deliberately NOT through
- * `requireCapability`/`public.has_capability()`. `has_capability()` is
- * defined by `004_roles_and_capabilities.sql`; a site that has upgraded
- * this package but not yet applied that migration has no such function in
- * its database, and every `requireCapability` call would throw. If
- * `requireAdmin` routed through it too, that would 403 the one route
- * (`/api/migrations/*`) an admin needs to actually apply the migration —
- * a deadlock with no escape through the UI. `public.is_admin()` has existed
- * since `002_admin_hardening.sql` and is only ever `create or replace`d,
- * never dropped, so it is always safe to call regardless of which layer
- * migrations have been applied. This is also why the migrations routes
- * call `requireAdmin` specifically, and not a named capability like
- * `system:migrate` — migrations are a bootstrapping concern and must never
- * depend on the capability system migrations themselves create.
+ * Queries `public.profiles.is_admin` directly — deliberately NOT
+ * `public.is_admin()` or `public.has_capability()`. Both of those are
+ * defined by migrations (`002_admin_hardening.sql`,
+ * `004_roles_and_capabilities.sql` respectively); a genuinely fresh site
+ * that has never applied any migration beyond the original baseline
+ * schema — an expected, normal state, not a broken one — has neither
+ * function. `/api/migrations/*` (the only routes that call `requireAdmin`
+ * today) are the one place this actually bites: they are the routes that
+ * apply a pending migration, so they must work with zero migrations
+ * applied, not just with `002`+ already in place. An earlier version of
+ * this function called `public.is_admin()` on the theory that it "always
+ * exists" — true for a site that has applied at least `002`, false for a
+ * fresh one that has not, which is exactly the case that matters here.
+ * `profiles.is_admin` (the column) is part of the original baseline
+ * schema itself, before any of this project's layered migrations existed,
+ * so querying it directly has no migration dependency at all.
+ *
+ * The trade-off: a user granted the `admin` role only through
+ * `user_roles` (see `permissions-storage/SKILL.md`'s "Granting a role by
+ * hand"), with `profiles.is_admin` left `false`, cannot pass this check —
+ * only RLS and `has_capability()`-gated routes recognize a role-only
+ * admin. That is an acceptable, narrow limitation: `user_roles` cannot
+ * exist before `004` has been applied, so a role-only admin can only
+ * exist on a site that has already applied every current migration, at
+ * which point there is nothing left for that admin to need
+ * `/admin/migrations` for. If a future migration ever needs applying by
+ * a role-only admin, grant them `profiles.is_admin = true` too.
+ *
+ * `serverSupabaseUser` (from `@nuxtjs/supabase`, backed by
+ * `client.auth.getClaims()`) returns decoded JWT claims, not a Supabase
+ * `User` row — the claims object has no `id` field, only `sub`. Querying
+ * `.eq('id', user.id)` silently matches zero rows and looks exactly like
+ * "not an admin" even for a real admin. Always read `user.sub`.
  *
  * Throws a 401 if there is no logged-in user, or a 403 if the user is not
- * an admin. Returns the user's claims on success. See capability-guard.ts
- * for the same user.sub vs user.id note — this function has the same
- * shape but never reads either field either.
+ * an admin. Returns the user's claims on success.
  */
 export async function requireAdmin(event: H3Event) {
   const user = await serverSupabaseUser(event)
@@ -32,9 +49,21 @@ export async function requireAdmin(event: H3Event) {
   }
 
   const client = await serverSupabaseClient<Database>(event)
-  const { data, error } = await client.rpc('is_admin')
+  const { data: profile, error } = await client
+    .from('profiles')
+    .select('is_admin')
+    .eq('id', user.sub)
+    .single()
+
+  if (error) {
+    // Logged, never returned: the 403 below must not tell an untrusted
+    // caller whether it hit a real error (a missing column, a connection
+    // problem) or a genuine non-admin. Server logs are where that
+    // distinction has to live instead.
+    console.error('requireAdmin: profiles lookup failed:', error.message)
+  }
 
-  if (error || data !== true) {
+  if (error || !profile?.is_admin) {
     throw createError({ statusCode: 403, statusMessage: 'Your account is not an admin.' })
   }