feat(creator-packs): add RLS policy and integrate Supabase client#51
Conversation
|
@Coder-soft is attempting to deploy a commit to the yamura3's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 51 minutes and 49 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR introduces MCP integration configuration, updates the Hero component to feature creator packs navigation, enhances logging in the pack fetching hook, modifies Supabase client authentication setup, and establishes row-level security policies for the creator_packs table. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR adds RLS policies for the
Confidence Score: 3/5Not safe to merge — two P1 defects will break the Supabase client initialization and disable admin pack review in production. Two active P1 bugs: the env-var rename silently kills all frontend Supabase calls in un-updated environments, and the missing admin RLS policy permanently blocks the pack review workflow for admins. src/integrations/supabase/client.ts and supabase/migrations/20260420000000_creator_packs_rls_policy.sql require fixes before merging.
|
| Filename | Overview |
|---|---|
| src/integrations/supabase/client.ts | Env var renamed from VITE_SUPABASE_ANON_KEY to VITE_SUPABASE_PUBLISHABLE_KEY — breaks if deployment env isn't updated; inconsistent with api/deleteAccount.js which still reads the old name. |
| supabase/migrations/20260420000000_creator_packs_rls_policy.sql | Adds public read and owner-management RLS policies, but omits an admin/reviewer policy required by the reviewPack function, which will silently block all pack approvals/rejections. |
| src/hooks/useCreatorPacks.ts | Enhanced error logging in fetchPacks; debug console.log left in on line 128 should be removed before merging. |
| src/components/Hero.tsx | Hero CTA buttons updated to point to creator-packs and music-packs tabs respectively — straightforward UI routing change. |
| opencode.json | New IDE config file committed to the repo; contains the Supabase project ref and should instead be gitignored. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Supabase Client Init] -->|reads VITE_SUPABASE_PUBLISHABLE_KEY| B{Key defined?}
B -- Yes --> C[Client initialized ✓]
B -- No / undefined --> D[All DB calls fail ✗]
E[User visits site] --> F[fetchPacks]
F --> G[(creator_packs RLS)]
G -->|Policy: status = approved| H[Public read ✓]
I[Authenticated user] --> J[createPack / updatePack / deletePack]
J --> G
G -->|Policy: auth.uid = user_id| K[Owner write ✓]
L[Admin calls reviewPack] --> M[UPDATE by id only]
M --> G
G -->|No admin policy exists| N[Blocked by RLS ✗]
Reviews (1): Last reviewed commit: "feat(creator-packs): add RLS policy and ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| const SUPABASE_URL = import.meta.env.VITE_SUPABASE_URL as string; | ||
| const SUPABASE_PUBLISHABLE_KEY = import.meta.env.VITE_SUPABASE_ANON_KEY as string; | ||
| const SUPABASE_PUBLISHABLE_KEY = import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY as string; |
There was a problem hiding this comment.
api/deleteAccount.js
client.ts now reads VITE_SUPABASE_PUBLISHABLE_KEY, but api/deleteAccount.js (line 36) still reads VITE_SUPABASE_ANON_KEY. Any deployment environment that has not yet added the new variable name will initialize the Supabase client with undefined as the API key, causing every database call in the frontend to silently fail. The server-side account-deletion flow also retains the old name, creating a permanent inconsistency.
Either revert the rename to keep using the standard VITE_SUPABASE_ANON_KEY, or update api/deleteAccount.js and all deployment environments atomically with this PR.
| CREATE POLICY "Users can manage their own creator packs" ON creator_packs | ||
| FOR ALL | ||
| USING (auth.uid() = user_id) | ||
| WITH CHECK (auth.uid() = user_id); No newline at end of file |
There was a problem hiding this comment.
reviewPack will be silently blocked
The reviewPack function in useCreatorPacks.ts updates status and review_reason on packs the admin does not own (using only .eq('id', id), no user_id filter). With the new policies in place, that UPDATE will be blocked by RLS for any row where auth.uid() ≠ user_id, causing the function to return zero rows or an RLS error and leaving packs permanently stuck in pending.
A reviewer/admin policy is needed, consistent with the pattern used elsewhere in the codebase (e.g. auth.jwt() ->> 'email' = 'yamura@duck.com'):
CREATE POLICY "Admins can review creator packs" ON creator_packs
FOR UPDATE
USING (auth.jwt() ->> 'email' = 'yamura@duck.com')
WITH CHECK (auth.jwt() ->> 'email' = 'yamura@duck.com');| }); | ||
| throw error; | ||
| } | ||
| console.log('Fetched packs:', data); |
There was a problem hiding this comment.
console.log left in production code
This log will print every fetched pack record to the browser console in production. It should be removed before merging.
| "mcp": { | ||
| "supabase": { | ||
| "type": "remote", | ||
| "url": "https://mcp.supabase.com/mcp?project_ref=bmywdrwjdqmrkafhiuwn&features=docs%2Cdatabase%2Cdebugging%2Cdevelopment%2Cfunctions%2Cbranching", |
There was a problem hiding this comment.
opencode.json is an AI-IDE config file that encodes the Supabase project reference directly in the URL. While the project ref alone is not a secret key, committing IDE-specific tooling configs to the repository creates noise and unnecessarily exposes the project identifier. This file should be added to .gitignore rather than tracked.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/hooks/useCreatorPacks.ts (1)
119-138:⚠️ Potential issue | 🟡 MinorDebug logging is fine, but trim noise and restore user-facing error feedback.
Two small concerns in this catch/log block:
console.log('Fetched packs:', data)logs every approved pack on every fetch in production — consider gating behindimport.meta.env.DEVor removing before merge.- The catch now logs the error twice (
'Error fetching creator packs:'and'Error details:') but — unlike sibling fetchers such asfetchUserPacks/fetchPendingPacks— no longer surfaces atoast.error(...)to the user. A silent empty list on failure is worse UX than the previous behavior.♻️ Suggested cleanup
- if (error) { - console.error('Supabase error details:', { - message: error.message, - details: error.details, - hint: error.hint, - code: error.code - }); - throw error; - } - console.log('Fetched packs:', data); + if (error) { + console.error('Supabase error fetching creator packs:', { + message: error.message, + details: error.details, + hint: error.hint, + code: error.code, + }); + throw error; + } + if (import.meta.env.DEV) { + console.debug('Fetched packs:', data?.length); + } setPacks((data as CreatorPackWithProfiles[])?.map(mapToCreatorPack) || []); } catch (error: unknown) { - console.error('Error fetching creator packs:', error); - if (error && typeof error === 'object' && 'message' in error) { - console.error('Error details:', (error as { message: unknown }).message); - } + console.error('Error fetching creator packs:', getErrorMessage(error)); + toast.error('Failed to load creator packs.'); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/hooks/useCreatorPacks.ts` around lines 119 - 138, The catch/log block in useCreatorPacks is noisy and omits user feedback: remove or gate the noisy console.log('Fetched packs:', data) behind import.meta.env.DEV (or delete it), collapse duplicate error logs into a single console.error that includes the error message, and restore user-facing feedback by calling the same toast.error(...) pattern used in fetchUserPacks/fetchPendingPacks inside the catch (use the error.message when available); ensure setIsLoading(false) remains in finally and keep setPacks((data as CreatorPackWithProfiles[])?.map(mapToCreatorPack) || []) unchanged.
🧹 Nitpick comments (2)
src/components/Hero.tsx (1)
123-154: Route changes look correct; consider aligning the "NEW" badge copy.Both
?tab=creator-packsand?tab=music-packsare handled byResourcesHub.tsx(Lines 111–117 and 276–295), so the new CTAs will activate the correct tab. 👍Minor copy nit: the NEW badge on Line 127 still reads “Music Packs On Resources Hub” while the primary CTA has been promoted to Creator Packs. If creator packs are the new headline feature, it may read more consistently as something like “Creator Packs On Resources Hub”. Non-blocking.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/Hero.tsx` around lines 123 - 154, Update the NEW badge copy to match the promoted CTA by changing the badge text (the span that currently says "Music Packs On Resources Hub") to reference Creator Packs instead (e.g., "Creator Packs On Resources Hub") so it aligns with the Link to="/resources?tab=creator-packs" CTA in Hero.tsx; locate the badge span element near the inline-flex container wrapping the NEW pill and update its inner text accordingly.opencode.json (1)
1-10: Consider whether this editor/tooling config belongs in the repo.
opencode.jsonis personal IDE/tooling config for the OpenCode MCP integration. Theproject_refembedded in the URL isn’t secret (it’s present in the public Supabase URL), but committing editor tooling config generally causes churn and can confuse collaborators who don’t use OpenCode. Consider either:
- Adding it to
.gitignoreand keeping it local, or- Documenting it in
README.md/CONTRIBUTING.mdso contributors understand its purpose.No functional impact on the app.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@opencode.json` around lines 1 - 10, opencode.json contains personal OpenCode MCP/editor tooling settings (the "mcp" -> "supabase" block including the "project_ref" in the URL) which should not be committed as repo-level config; either remove opencode.json from the repo and add it to .gitignore, or keep the file but add a short note in README.md or CONTRIBUTING.md explaining the purpose of the "mcp"/"supabase" entry and why contributors can ignore it so collaborators aren’t confused by the editor-specific config.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/integrations/supabase/client.ts`:
- Line 6: The backend is still reading VITE_SUPABASE_ANON_KEY while the frontend
uses VITE_SUPABASE_PUBLISHABLE_KEY, causing a runtime mismatch; update
api/deleteAccount.js to read VITE_SUPABASE_PUBLISHABLE_KEY if you want parity,
but preferably switch the backend to use the Supabase service-role key (e.g.,
SUPABASE_SERVICE_ROLE_KEY) for privileged operations instead of any
publishable/anon key; change the environment variable reference in
api/deleteAccount.js, update any Supabase client initialization there to use the
service-role key variable (and keep VITE_SUPABASE_PUBLISHABLE_KEY only for
front-end usage), and add a note to the deployment/env setup docs or README
explaining this breaking env-var rename so contributors update their .env
accordingly.
In `@supabase/migrations/20260420000000_creator_packs_rls_policy.sql`:
- Around line 1-14: Add an "ENABLE ROW LEVEL SECURITY" statement for the
creator_packs table before the CREATE POLICY statements so the policies take
effect; modify the migration to execute ALTER TABLE creator_packs ENABLE ROW
LEVEL SECURITY (before creating "Creator packs are publicly readable if
approved" and "Users can manage their own creator packs") ensuring the RLS is
enabled defensively just like resources migration so the FOR ALL / USING
policies on creator_packs apply.
---
Outside diff comments:
In `@src/hooks/useCreatorPacks.ts`:
- Around line 119-138: The catch/log block in useCreatorPacks is noisy and omits
user feedback: remove or gate the noisy console.log('Fetched packs:', data)
behind import.meta.env.DEV (or delete it), collapse duplicate error logs into a
single console.error that includes the error message, and restore user-facing
feedback by calling the same toast.error(...) pattern used in
fetchUserPacks/fetchPendingPacks inside the catch (use the error.message when
available); ensure setIsLoading(false) remains in finally and keep
setPacks((data as CreatorPackWithProfiles[])?.map(mapToCreatorPack) || [])
unchanged.
---
Nitpick comments:
In `@opencode.json`:
- Around line 1-10: opencode.json contains personal OpenCode MCP/editor tooling
settings (the "mcp" -> "supabase" block including the "project_ref" in the URL)
which should not be committed as repo-level config; either remove opencode.json
from the repo and add it to .gitignore, or keep the file but add a short note in
README.md or CONTRIBUTING.md explaining the purpose of the "mcp"/"supabase"
entry and why contributors can ignore it so collaborators aren’t confused by the
editor-specific config.
In `@src/components/Hero.tsx`:
- Around line 123-154: Update the NEW badge copy to match the promoted CTA by
changing the badge text (the span that currently says "Music Packs On Resources
Hub") to reference Creator Packs instead (e.g., "Creator Packs On Resources
Hub") so it aligns with the Link to="/resources?tab=creator-packs" CTA in
Hero.tsx; locate the badge span element near the inline-flex container wrapping
the NEW pill and update its inner text accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: eb9457aa-9aa2-4377-a5d4-02893b7a1c78
📒 Files selected for processing (5)
opencode.jsonsrc/components/Hero.tsxsrc/hooks/useCreatorPacks.tssrc/integrations/supabase/client.tssupabase/migrations/20260420000000_creator_packs_rls_policy.sql
|
|
||
| const SUPABASE_URL = import.meta.env.VITE_SUPABASE_URL as string; | ||
| const SUPABASE_PUBLISHABLE_KEY = import.meta.env.VITE_SUPABASE_ANON_KEY as string; | ||
| const SUPABASE_PUBLISHABLE_KEY = import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY as string; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find any remaining references to the old env var name across the repo.
rg -nP '\bVITE_SUPABASE_ANON_KEY\b|\bSUPABASE_ANON_KEY\b' -C2
# Also check env example files.
fd -HI -t f '\.env' -x rg -nH 'SUPABASE' {}Repository: creatorcluster/renderdragon.org
Length of output: 547
🏁 Script executed:
#!/bin/bash
# 1. Verify the client.ts file has the new env var name
echo "=== Checking src/integrations/supabase/client.ts ==="
head -20 src/integrations/supabase/client.ts
# 2. Find all .env* files
echo -e "\n=== All .env* files in repo ==="
fd -HI '\.env' --type f
# 3. Check content of env example files
echo -e "\n=== Checking .env example files ==="
fd -HI '\.env.*example' --type f -x cat -n {}
# 4. Find all backend handlers (common patterns)
echo -e "\n=== Checking for SUPABASE env vars in all backend/api handlers ==="
rg -l 'VITE_SUPABASE|SUPABASE_(ANON|URL|KEY)' api/ --type js --type ts 2>/dev/null | head -20
# 5. Check all references to both old and new env var names
echo -e "\n=== All references to SUPABASE env vars (new and old) ==="
rg 'VITE_SUPABASE_(PUBLISHABLE_KEY|ANON_KEY)|SUPABASE_(ANON_KEY|PUBLISHABLE_KEY)' -nRepository: creatorcluster/renderdragon.org
Length of output: 1235
Update backend to match renamed env var — this is a breaking change.
The frontend now reads VITE_SUPABASE_PUBLISHABLE_KEY, but api/deleteAccount.js (line 36) still reads VITE_SUPABASE_ANON_KEY. This mismatch will cause the backend to fail at runtime when users deploy this change without manually coordinating their .env configuration.
Update api/deleteAccount.js line 36 to read VITE_SUPABASE_PUBLISHABLE_KEY or (preferably) switch to the Supabase service-role key on the backend instead of the publishable/anon key.
Since no .env.example file currently exists in the repo, ensure any deployment documentation or environment setup notes call out this breaking change for contributors.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/integrations/supabase/client.ts` at line 6, The backend is still reading
VITE_SUPABASE_ANON_KEY while the frontend uses VITE_SUPABASE_PUBLISHABLE_KEY,
causing a runtime mismatch; update api/deleteAccount.js to read
VITE_SUPABASE_PUBLISHABLE_KEY if you want parity, but preferably switch the
backend to use the Supabase service-role key (e.g., SUPABASE_SERVICE_ROLE_KEY)
for privileged operations instead of any publishable/anon key; change the
environment variable reference in api/deleteAccount.js, update any Supabase
client initialization there to use the service-role key variable (and keep
VITE_SUPABASE_PUBLISHABLE_KEY only for front-end usage), and add a note to the
deployment/env setup docs or README explaining this breaking env-var rename so
contributors update their .env accordingly.
| -- Drop existing policies if they exist to avoid conflicts | ||
| DROP POLICY IF EXISTS "Creator packs are publicly readable if approved" ON creator_packs; | ||
| DROP POLICY IF EXISTS "Users can manage their own creator packs" ON creator_packs; | ||
|
|
||
| -- Allow anyone to read approved creator packs | ||
| CREATE POLICY "Creator packs are publicly readable if approved" ON creator_packs | ||
| FOR SELECT | ||
| USING (status = 'approved'); | ||
|
|
||
| -- Allow users to insert, update, and delete their own creator packs | ||
| CREATE POLICY "Users can manage their own creator packs" ON creator_packs | ||
| FOR ALL | ||
| USING (auth.uid() = user_id) | ||
| WITH CHECK (auth.uid() = user_id); No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check whether an earlier migration already enables RLS on creator_packs.
rg -nP -C2 'creator_packs' --iglob 'supabase/migrations/*.sql' | rg -n -i 'row level security|enable row|rls'Repository: creatorcluster/renderdragon.org
Length of output: 1548
🏁 Script executed:
# Find all migrations related to creator_packs to understand the sequence
ls -1 supabase/migrations/*.sql | sort
# Search for the migration that creates the creator_packs table
rg -l 'CREATE TABLE.*creator_packs' supabase/migrations/
# Search for any ENABLE ROW LEVEL SECURITY statements on creator_packs across all migrations
rg 'ALTER TABLE creator_packs.*ENABLE ROW LEVEL SECURITY' supabase/migrations/Repository: creatorcluster/renderdragon.org
Length of output: 640
🏁 Script executed:
# Search all migrations for any mention of creator_packs
rg 'creator_packs' supabase/migrations/ -l
# Also check if there's a schema.sql or initial schema file
find supabase -name "*.sql" -type f | sort
# Get full content of migrations that mention creator_packs
rg 'creator_packs' supabase/migrations/ --no-filename -B5 -A5Repository: creatorcluster/renderdragon.org
Length of output: 1321
🏁 Script executed:
# Check all SQL files in supabase directory
find supabase -name "*.sql" -type f
# Search in schema files for creator_packs table definition
rg 'CREATE TABLE.*creator_packs' supabase/Repository: creatorcluster/renderdragon.org
Length of output: 640
🏁 Script executed:
# Broader search for creator_packs anywhere in the codebase
rg 'creator_packs' . --type-list
# Also search TypeScript/JavaScript files
rg 'creator_packs' . -t ts -t tsx -t js -t json
# Check if there's any Prisma schema or other ORM definitions
find . -name "*.prisma" -o -name "schema.prisma"Repository: creatorcluster/renderdragon.org
Length of output: 492
🏁 Script executed:
# Search for creator_packs in entire repo
rg 'creator_packs' . --no-heading -n
# Also check specific directories for any table/schema definitions
rg 'creator_packs' src/ --no-heading -n 2>/dev/null || true
# Check if there's a types or schema directory
ls -la src/ 2>/dev/null | head -20Repository: creatorcluster/renderdragon.org
Length of output: 3342
🏁 Script executed:
# Check the supabase types file to understand table definition
head -n 200 src/integrations/supabase/types.ts | tail -n 50
# Look for any schema or seed files in supabase directory
find supabase -type f -name "*.json" -o -name "*schema*" -o -name "*seed*"
# Check if there's a Supabase config or any other initialization
cat supabase/config.json 2>/dev/null || true
ls -la supabase/ | head -20Repository: creatorcluster/renderdragon.org
Length of output: 1782
🏁 Script executed:
# Check git log to see if creator_packs table creation is in an earlier commit
git log --all --oneline --source --remotes -- supabase/migrations/ | head -20
# Check if there are any other branches or stashes
git branch -a
# Search for any mention of "creator_packs" in recent commits
git log --all -S 'creator_packs' --oneline | head -10Repository: creatorcluster/renderdragon.org
Length of output: 161
🏁 Script executed:
# Check all SQL migration files for any ENABLE ROW LEVEL SECURITY statements
rg 'ENABLE ROW LEVEL SECURITY|FORCE ROW LEVEL SECURITY' supabase/migrations/Repository: creatorcluster/renderdragon.org
Length of output: 206
Add ENABLE ROW LEVEL SECURITY to the creator_packs table.
CREATE POLICY statements have no effect unless RLS is enabled on the table. This migration creates policies but does not enable RLS, meaning the table remains unprotected. The resources table enables RLS in an earlier migration, but creator_packs does not. Add this defensively before the policies:
Required addition
-- Drop existing policies if they exist to avoid conflicts
DROP POLICY IF EXISTS "Creator packs are publicly readable if approved" ON creator_packs;
DROP POLICY IF EXISTS "Users can manage their own creator packs" ON creator_packs;
+-- Ensure RLS is enabled
+ALTER TABLE creator_packs ENABLE ROW LEVEL SECURITY;
+
-- Allow anyone to read approved creator packs
CREATE POLICY "Creator packs are publicly readable if approved" ON creator_packsThe FOR ALL USING (auth.uid() = user_id) policy correctly allows users to select their own rows regardless of status—this matches the intended behavior in useCreatorPacks.ts where fetchUserPacks retrieves a user's own pending/rejected packs.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| -- Drop existing policies if they exist to avoid conflicts | |
| DROP POLICY IF EXISTS "Creator packs are publicly readable if approved" ON creator_packs; | |
| DROP POLICY IF EXISTS "Users can manage their own creator packs" ON creator_packs; | |
| -- Allow anyone to read approved creator packs | |
| CREATE POLICY "Creator packs are publicly readable if approved" ON creator_packs | |
| FOR SELECT | |
| USING (status = 'approved'); | |
| -- Allow users to insert, update, and delete their own creator packs | |
| CREATE POLICY "Users can manage their own creator packs" ON creator_packs | |
| FOR ALL | |
| USING (auth.uid() = user_id) | |
| WITH CHECK (auth.uid() = user_id); | |
| -- Drop existing policies if they exist to avoid conflicts | |
| DROP POLICY IF EXISTS "Creator packs are publicly readable if approved" ON creator_packs; | |
| DROP POLICY IF EXISTS "Users can manage their own creator packs" ON creator_packs; | |
| -- Ensure RLS is enabled | |
| ALTER TABLE creator_packs ENABLE ROW LEVEL SECURITY; | |
| -- Allow anyone to read approved creator packs | |
| CREATE POLICY "Creator packs are publicly readable if approved" ON creator_packs | |
| FOR SELECT | |
| USING (status = 'approved'); | |
| -- Allow users to insert, update, and delete their own creator packs | |
| CREATE POLICY "Users can manage their own creator packs" ON creator_packs | |
| FOR ALL | |
| USING (auth.uid() = user_id) | |
| WITH CHECK (auth.uid() = user_id); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@supabase/migrations/20260420000000_creator_packs_rls_policy.sql` around lines
1 - 14, Add an "ENABLE ROW LEVEL SECURITY" statement for the creator_packs table
before the CREATE POLICY statements so the policies take effect; modify the
migration to execute ALTER TABLE creator_packs ENABLE ROW LEVEL SECURITY (before
creating "Creator packs are publicly readable if approved" and "Users can manage
their own creator packs") ensuring the RLS is enabled defensively just like
resources migration so the FOR ALL / USING policies on creator_packs apply.
2 participants
Changes
Summary by CodeRabbit
Release Notes
New Features
Security
Improvements