@rebasepro/server-postgres 0.14.1 → 0.14.2-canary.g991e9df

package/dist/utils/pg-error-utils.d.ts

@@ -73,6 +73,33 @@ export declare function classifyConnectFailure(error: unknown): ConnectFailure;
  * error to the Studio SQL Editor user.
  */
 export declare function isRoleSwitchingPermissionError(error: unknown): boolean;
+/**
+ * Was this `42501` the *caller* being refused by a policy, rather than the
+ * server lacking a privilege?
+ *
+ * Both arrive as `insufficient_privilege`, and they are opposite kinds of
+ * problem. A row-level-security refusal is a working access-control system
+ * doing its job: the caller asked for something their policies do not permit,
+ * which is a 403 and nobody's bug. A missing `GRANT` is the deployment being
+ * wrong — the connection role cannot touch the table at all, no policy is
+ * involved, and nothing the caller changes about the request will help.
+ *
+ * Postgres distinguishes them in the message, so this does too:
+ *
+ *     new row violates row-level security policy for table "notes"  → the caller
+ *     permission denied for table notes                             → the server
+ *
+ * Only writes reach this. A read that RLS excludes is not an error — the rows
+ * are filtered and the caller gets an empty page — so the erroring case is
+ * specifically an `INSERT`/`UPDATE` whose row fails a policy's `WITH CHECK`.
+ *
+ * Matched on the message because that is the only thing carrying the
+ * distinction; the SQLSTATE is identical either way. Narrow by design: anything
+ * not naming row-level security stays the server's problem, since reporting a
+ * genuine privilege misconfiguration as "forbidden" would send an operator
+ * hunting for a policy bug that does not exist.
+ */
+export declare function isRowLevelSecurityDenial(error: unknown): boolean;
 /**
  * Translate a raw PostgreSQL error into a user-friendly message.
  *

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/server-postgres",
   "type": "module",
-  "version": "0.14.1",
+  "version": "0.14.2-canary.g991e9df",
   "description": "PostgreSQL data source backend implementation for Rebase with Drizzle ORM",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"
@@ -47,11 +47,11 @@
     "execa": "^9.6.1",
     "pg": "^8.22.0",
     "ws": "^8.21.1",
-    "@rebasepro/codegen": "0.14.1",
-    "@rebasepro/common": "0.14.1",
-    "@rebasepro/server": "0.14.1",
-    "@rebasepro/utils": "0.14.1",
-    "@rebasepro/types": "0.14.1"
+    "@rebasepro/codegen": "0.14.2-canary.g991e9df",
+    "@rebasepro/common": "0.14.2-canary.g991e9df",
+    "@rebasepro/server": "0.14.2-canary.g991e9df",
+    "@rebasepro/types": "0.14.2-canary.g991e9df",
+    "@rebasepro/utils": "0.14.2-canary.g991e9df"
   },
   "devDependencies": {
     "@hono/node-server": "^2.0.12",

package/src/services/PersistService.ts

@@ -26,7 +26,7 @@ import {
     type NestedPathHop
 } from "./nested-path";
 import { ApiError, logger } from "@rebasepro/server";
-import { extractPgError, extractCauseMessage, pgErrorToFriendlyMessage } from "../utils/pg-error-utils";
+import { extractPgError, extractCauseMessage, pgErrorToFriendlyMessage, isRowLevelSecurityDenial } from "../utils/pg-error-utils";
 import { explainZeroRowWrite } from "./write-denial";
 
 /**
@@ -511,12 +511,33 @@ export class PersistService {
             // reported to callers as a bad request. Classes 22 (data exception)
             // and 23 (integrity constraint violation) are the caller's data;
             // everything else — a dropped connection, a missing column, a
-            // permission problem — is ours, and stays a 500.
+            // *privilege* problem — is ours, and stays a 500.
             if (/^2[23]/.test(code)) {
                 return code === "23505"
                     ? ApiError.conflict(message, `PG_${code}`)
                     : ApiError.badRequest(message, `PG_${code}`);
             }
+            // With one exception inside class 42: a row-level-security policy
+            // refusing the caller is not a fault at all, it is access control
+            // working. It fell through to the 500 below, so the client could not
+            // tell "you may not do this" from "the server is broken" — and a
+            // 500's message is sanitized on the way out, so the reason was lost
+            // too. `expected`, because a caller attempting what their policies
+            // forbid is routine and should not page anyone; that is the same
+            // treatment `unauthenticated()` gets one status code down.
+            // `WRITE_DENIED`, the same code `explainZeroRowWrite` returns for an
+            // UPDATE or DELETE that RLS refused. Those already answered 403; only
+            // INSERT reached here, because a failed `WITH CHECK` raises 42501 while
+            // a refused UPDATE simply matches no rows. Two spellings of one denial
+            // should not be two status codes.
+            //
+            // Left at the default log level rather than `expected`: `ApiError`'s
+            // own documentation puts "a permission the database refused" in the
+            // stays-at-warn column, and the status code is the defect here. The
+            // log level is a separate decision that already has an answer.
+            if (isRowLevelSecurityDenial(error)) {
+                return ApiError.forbidden(message, "WRITE_DENIED");
+            }
             return new Error(message);
         }
 

package/src/utils/pg-error-utils.ts

@@ -178,6 +178,38 @@ export function isRoleSwitchingPermissionError(error: unknown): boolean {
     return msg.includes("set role") || msg.includes("member of role");
 }
 
+/**
+ * Was this `42501` the *caller* being refused by a policy, rather than the
+ * server lacking a privilege?
+ *
+ * Both arrive as `insufficient_privilege`, and they are opposite kinds of
+ * problem. A row-level-security refusal is a working access-control system
+ * doing its job: the caller asked for something their policies do not permit,
+ * which is a 403 and nobody's bug. A missing `GRANT` is the deployment being
+ * wrong — the connection role cannot touch the table at all, no policy is
+ * involved, and nothing the caller changes about the request will help.
+ *
+ * Postgres distinguishes them in the message, so this does too:
+ *
+ *     new row violates row-level security policy for table "notes"  → the caller
+ *     permission denied for table notes                             → the server
+ *
+ * Only writes reach this. A read that RLS excludes is not an error — the rows
+ * are filtered and the caller gets an empty page — so the erroring case is
+ * specifically an `INSERT`/`UPDATE` whose row fails a policy's `WITH CHECK`.
+ *
+ * Matched on the message because that is the only thing carrying the
+ * distinction; the SQLSTATE is identical either way. Narrow by design: anything
+ * not naming row-level security stays the server's problem, since reporting a
+ * genuine privilege misconfiguration as "forbidden" would send an operator
+ * hunting for a policy bug that does not exist.
+ */
+export function isRowLevelSecurityDenial(error: unknown): boolean {
+    const pgError = extractPgError(error);
+    if (!pgError || pgError.code !== "42501") return false;
+    return pgError.message.toLowerCase().includes("row-level security policy");
+}
+
 /**
  * Translate a raw PostgreSQL error into a user-friendly message.
  *
@@ -249,10 +281,23 @@ export function pgErrorToFriendlyMessage(pgError: PostgresError, context: string
                 code
             };
         case "42501": // insufficient_privilege
-            return {
-                message: `Permission denied on "${tableRef}". Check your database credentials and RLS policies.${suffix}`,
-                code
-            };
+            // Two unrelated failures share this SQLSTATE, and the old message
+            // named both causes because it could not tell them apart — which
+            // meant it was half wrong whichever one had happened, and sent the
+            // reader to check the other. Postgres says which in its own message.
+            return pgMessage.toLowerCase().includes("row-level security policy")
+                ? {
+                    // The caller. Their policies do not permit this row; the
+                    // deployment is working exactly as configured.
+                    message: `Not permitted to write this row in "${tableRef}": it does not satisfy the row-level security policy.${suffix}`,
+                    code
+                }
+                : {
+                    // The deployment. No policy is involved — the connecting
+                    // role cannot touch the table at all.
+                    message: `Permission denied on "${tableRef}": the database role this server connects as lacks privileges on it.${suffix}`,
+                    code
+                };
         case "28000": // invalid_authorization_specification
             return {
                 message: `Authorization failed for "${context}". Check your database credentials.${suffix}`,