@orion-studios/cms 0.5.0 → 0.5.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,11 +1,11 @@
1
- import {
2
- CONTENT_CACHE_TAG
3
- } from "../chunk-HVJCF2IZ.js";
4
1
  import {
5
2
  createMemoryRateLimitStore,
6
3
  isOriginAllowed,
7
4
  processSubmission
8
5
  } from "../chunk-VPUODCNH.js";
6
+ import {
7
+ CONTENT_CACHE_TAG
8
+ } from "../chunk-HVJCF2IZ.js";
9
9
 
10
10
  // src/server/routes.ts
11
11
  import { createHash as createHash2 } from "crypto";
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@orion-studios/cms",
3
- "version": "0.5.0",
3
+ "version": "0.5.1",
4
4
  "description": "Orion CMS v2 core engine \u2014 JSONB content model on Supabase primitives",
5
5
  "type": "module",
6
6
  "exports": {
@@ -0,0 +1,17 @@
1
+ -- Enable RLS on the two bookkeeping tables the original schema missed.
2
+ -- Neither has policies on purpose: no client role has any business touching
3
+ -- them. cms_rate_limits is only written via cms_rate_limit_consume(), which is
4
+ -- SECURITY DEFINER and service-role-execute-only; cms_migrations is only
5
+ -- touched by the migration runner over a direct Postgres connection. With RLS
6
+ -- off, both tables were fully readable/writable by anon via the Data API
7
+ -- (Supabase security advisor: rls_disabled, critical).
8
+
9
+ alter table cms_rate_limits enable row level security;
10
+
11
+ do $rls$
12
+ begin
13
+ if to_regclass('public.cms_migrations') is not null then
14
+ execute 'alter table cms_migrations enable row level security';
15
+ end if;
16
+ end
17
+ $rls$;