DEV Community: Tori TIC

Supabase: permission denied for table (42501)

Tori TIC — Sun, 04 Oct 2026 16:30:04 +0000

This is not row level security. The database role your app uses (anon or authenticated) has no privilege on the table at all, so Postgres refuses before any policy is read. A correct policy cannot fix it; a grant can. Supabase is also changing a default that makes this error easier to hit.

Same code, different error

from the app:  42501 permission denied for table notes
not this one:  42501 new row violates row-level security policy for table "notes"

What is permission denied for table? It is Postgres refusing a statement because the role running it holds no privilege (select, insert, update or delete) on that table. Supabase's API surfaces it as error 42501.

Both errors carry the code 42501, which is why they get mixed up. The text tells them apart. Supabase: "If you see an error like permission denied for table your_table, the querying role may not have the required privilege for the operation." A row level security violation names a policy. This one names only the table. Proven on a real PostgreSQL: with a correct select policy in place, a role that had its privileges revoked got permission denied for table on a select and on an insert; the policy never ran. A row that fails the insert policy of a role that does have the privilege got the other message, new row violates row-level security policy.

New tables stop being granted for you

Until now a table you created in the public schema was usable by the API roles straight away. Supabase's changelog (April 28, 2026): "New tables in the public schema will no longer be exposed to the Data API automatically." The dates it gives: from May 30, 2026 the setting starts to become the default for new projects (a gradual rollout), and on October 30, 2026 it is applied to existing projects. Existing tables are not affected; only tables created after the change reaches your project need the grant. And the advice: "For new tables you want to expose via the Data API, make explicit grants part of your table-creation flow." A table created by a migration that has no grant for the API roles gets exactly this error on the first query.

Ask the database what the role may do

Run this in the SQL editor, with your table name in place of your_table. If it returns f, the role has no select privilege and a grant is the fix. Proven: it returned f after the privilege was revoked and t after it was granted back.

select has_table_privilege('authenticated', 'public.your_table', 'select');

To see every privilege the API roles hold on the table:

select grantee, privilege_type from information_schema.role_table_grants
where table_schema = 'public' and table_name = 'your_table'
and grantee in ('anon', 'authenticated', 'service_role');

Grant the privilege, keep row security on

A grant decides whether the role may touch the table. Row level security still decides which rows. PostgreSQL: "In addition to the SQL-standard privilege system available through GRANT, tables can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands." So grant, and keep the policies. Proven: after the grant below, the owner reads their row, another signed-in user gets 0 rows and no error, and a row that fails the insert policy is refused with the policy message.

grant select, insert, update, delete on public.your_table to authenticated;

Grant only what the app needs: for a read-only table, select alone. Never grant to a role to make an error go away on a table that has row level security switched off, because then every row is open to anyone holding your public key. Our free auditor lists tables in that state.

Three look-alikes, each with its own message

A table another role created

Default grants belong to the role that set them up. PostgreSQL: "For most kinds of objects, the initial state is that only the owner (or a superuser) can do anything with the object." Proven: a table created by a different role, with a correct select policy, gave permission denied for table to the signed-in role until it was granted. Run the grant above.

A schema other than public

The message changes to permission denied for schema. PostgreSQL: usage on a schema "Essentially this allows the grantee to "look up" objects within the schema." Proven: with select granted on a table in a custom schema but no usage on the schema, the error named the schema; granting usage fixed it. Use your schema's name:

grant usage on schema app to authenticated;

A serial column and its sequence

An insert into a table with a serial id also uses a sequence, and the message names it: permission denied for sequence. PostgreSQL: "For sequences, allows use of the currval and nextval functions." Proven: with insert granted on the table but no usage on the sequence, the insert failed naming the sequence, and succeeded after this grant (the sequence is named after the table and column):

grant usage on sequence public.your_table_id_seq to authenticated;

Straight answers

Is permission denied for table the same as the row level security error?

No. Both carry the code 42501, but permission denied for table means the role has no privilege on the table, and no policy can change that. The row level security error says new row violates row-level security policy and names a policy. Proven on a real PostgreSQL: a correct select policy did not help a role whose privileges were revoked.

Does the service role need grants too?

Yes. The service role skips row level security but not privileges. Proven on a real PostgreSQL: after its privileges on a table were revoked, the service role also got permission denied for table.

Why did my new table work before and fail now?

Supabase's changelog says new tables in the public schema will no longer be exposed to the Data API automatically, from May 30, 2026 as the default for new projects (gradual rollout) and on October 30, 2026 for existing projects, and only for tables created after the change reaches your project. Add the grant to the migration that creates the table.

One missing grant is easy. The next one may be a hole

Our free auditor names every table whose policies never run because a grant is missing, and prints the GRANT for each, alongside the row level security holes, worst first. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42501, new row violates row-level security policy, auth.uid() returning null, or an app that works locally and not in production?

Still denied after the grant, or would rather hand it off? Paste the error into the free diagnosis at rescue.ticassociation.com, or send us the project: you pay only when the fix works.

Originally published with the full SQL and sources at https://ticassociation.com/supabase-permission-denied-for-table.

Supabase 42501: new row violates row-level security

Tori TIC — Thu, 01 Oct 2026 12:30:03 +0000

PostgreSQL refused the write because no policy let this user write this row. In a Supabase app that comes down to one of six causes, and three things tell you which: the table named in the error, the role making the request, and whether you asked for the row back.

What you are looking at

{
  "code": "42501",
  "message": "new row violates row-level security policy for table \"profiles\""
}

What is error 42501? 42501 is the PostgreSQL error code insufficient_privilege. PostgreSQL raises exactly this message, with exactly this code, when a new row fails a row level security check; you can see it in its executor's source. The same code also covers permission denied for table, which is a missing grant rather than a policy. That case is further down.

Six causes. Check them in this order

There is no insert policy for your role

With row level security on, PostgreSQL refuses anything no policy allows. In its own words: "If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified." Check the table's policies in your dashboard: is there an INSERT (or ALL) policy for the authenticated role? If not, add one:

create policy "insert own rows"
on public.profiles for insert to authenticated
with check ((select auth.uid()) = user_id);

The row you send fails the check

The policy exists, but the new row does not pass its WITH CHECK. The usual reason is that the app never sends user_id, or sends a different one. PostgreSQL: "Rows being inserted that do not pass this policy will result in a policy violation error, and the entire INSERT command will be aborted." Send the signed-in user's id, or let the database fill it in so the app cannot get it wrong:

alter table public.profiles alter column user_id set default auth.uid();

The request is not signed in

Your policy says to authenticated, but the request reached the database as the anonymous role: the client had no session yet, or a server route built its client without the user's session. Supabase: "Once RLS is enabled, no data is accessible through the API when using a publishable key, until you create policies." Check that a session exists right before the insert, and on the server build the client from the request's cookies. Do not widen the policy to anon to make the error go away.

You chained `.select()` after `.insert()`

Supabase's client returns nothing from an insert by default: "By default, inserted rows are not returned. To return it, chain the call with .select()." Asking for the row back adds a RETURNING clause, and then PostgreSQL also requires a SELECT policy the new row passes: "If a newly inserted or updated row does not satisfy the relation's SELECT policies, an error will be thrown." That is why the same insert works without .select() and fails with it. Add a select policy, or drop .select():

create policy "select own rows"
on public.profiles for select to authenticated
using ((select auth.uid()) = user_id);

It is an upsert

An upsert is an insert that may turn into an update, so it needs an update policy as well as an insert policy. When the row already exists, PostgreSQL checks it against your update policies and, as its documentation says, "unlike a standalone UPDATE command, if the existing row does not pass the USING expressions, an error will be thrown." It needs a select policy too: the same page says "the rows proposed for insertion are checked using the relation's SELECT policies", and on a real PostgreSQL an upsert of a new row with no select policy was refused with 42501. Add the update policy:

create policy "update own rows"
on public.profiles for update to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

It is a file upload

If the table in the error is objects, the refusal came from Supabase Storage, not your own table. Supabase: "By default Storage does not allow any uploads to buckets without RLS policies. You selectively allow certain operations by creating RLS policies on the storage.objects table." This lets signed-in users upload into one bucket; overwriting with upsert also needs SELECT and UPDATE policies. The four upload causes, a folder-scoped policy and the upsert policies are on the Storage upload page:

create policy "signed-in users can upload"
on storage.objects for insert to authenticated
with check (bucket_id = 'your-bucket');

Two fixes that trade the error for a leak

Do not switch row level security off. The error goes away because nothing is checked any more. Supabase gives its API roles access to tables in the public schema by default, so without RLS anyone holding your public key can read and write the table.

Do not move the insert to the secret key in the browser. Supabase: "A secret key authorizes access through the service_role Postgres role, which has the bypassrls attribute. Never use a secret key in the browser or expose it to customers."

Same code, different cause

If the message is permission denied for table, no policy was ever consulted: the role has no grant on the table at all. Supabase's own troubleshooting page explains that by default "tables in the public schema are granted SELECT, INSERT, UPDATE, and DELETE to the anon and authenticated roles". A table in a custom schema, or one whose grants were revoked, has to be granted again. The auth and vault schemas are closed to the API on purpose, so reach them through a security definer function instead.

grant select, insert, update, delete on table public.profiles to anon, authenticated;

Straight answers

Why does the same insert work in the SQL editor?

Because the dashboard runs your queries as the postgres role (Supabase: "Queries you run in the Dashboard execute as postgres"), the role that created, and so owns, your tables. PostgreSQL lets table owners skip row security: "Table owners normally bypass row security as well." Your users are not table owners, so the same insert is checked for them. When the app's request carries no session at all, auth.uid() is null and every ownership check fails; that case has its own page.

What does error 42501 mean in Supabase?

42501 is PostgreSQL's code for insufficient_privilege. With the message "new row violates row-level security policy", a row you tried to write failed a row level security check. With "permission denied for table", the role has no grant on the table.

Is it safe to just turn RLS off?

No. Supabase gives its API roles access to tables in the public schema by default, so a table without row level security is readable and writable by anyone holding your public key. Fix the policy instead.

One broken policy is rarely alone. Check every table

Our free auditor reads your policies and lists the holes worst first, including the quiet ones that never raise an error. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42P17, infinite recursion detected in policy?

Originally published with the full SQL and sources at https://ticassociation.com/supabase-42501-row-level-security.

How We Replaced 50/mo Social Growth Subscriptions with a Local Desktop Tool

Tori TIC — Sun, 26 Jul 2026 22:29:08 +0000

If you are a solo developer or indie hacker, you know the monthly subscription stack adds up fast.

Every tool wants $30 to $60 every single month just to run basic repetitive loops like audience targeting, account auditing, and following/unfollowing non-responders.

The Problem with Cloud SaaS for Personal Workflows

Monthly Subscription Tax: Paying $400 to $600 per year for simple automation loops.
Security & Credential Risk: Giving third-party servers your session cookies or password.
Overkill Complexity: Massive web dashboards when all you need is a reliable local script or app.

The Local Desktop Alternative

We built XDB (for X/Twitter) and IDB (for Instagram) as standalone, local-first Windows desktop tools.

Key Benefits

Zero Cloud Dependence: Everything runs on your own machine. Your credentials never touch a external server.
Safety Governor: Built-in human pacing delays prevent account blocks.
One-Time Purchase: Pay once ($29), keep it forever.

You can inspect the tools and local documentation here:

Built by the team at TIC Association.

Next.js App Shows a White Screen After Vercel Deploy: 5 Real Causes

Tori TIC — Mon, 20 Jul 2026 19:48:58 +0000

A Next.js app that works perfectly on your machine and shows a blank white page the moment Vercel deploys it is one of the most common ways an AI-built app breaks in production. It is also one of the most misleading, because "white screen" is not a cause. It is what five or six different causes all look like from the outside.

Here is how to actually narrow it down, in the order that catches the most cases fastest.

1. Open the browser console before anything else

A white screen almost always means the client-side JavaScript threw an error before it could render anything, and that error is sitting in the browser console even when nothing shows up in the Vercel deploy log. This single step splits the problem in half: if there is an error here, you are debugging client-side code. If the console is silent, the failure is happening before the client ever runs, which points at the next two checks instead.

2. Check for a missing environment variable

This is the single most common cause. Your .env.local file exists on your machine and never gets deployed, by design. If your code reads process.env.SOMETHING and that variable was never added in the Vercel project's Environment Variables settings, the value is undefined in production, and depending on how it is used, that can fail completely silently, especially if it is passed into a client SDK's constructor with no error handling around it. Check the Vercel deploy's Function Logs, not just the build log. A build can succeed while the actual request still fails.

3. Check whether the build genuinely succeeded, not just that it finished

Vercel will sometimes complete a build and still ship something broken if a data-fetching call at build time (generateStaticParams, a server component's own fetch) silently failed and got swallowed instead of throwing. The page "builds," but the HTML that gets served is empty or wrong. Look at the actual deployed HTML source (view source on the live URL, not the rendered page) and check whether meaningful content is even there before the JavaScript runs.

4. Check the output configuration if you changed frameworks or moved directories

If the project was migrated, restructured, or built with an AI tool that changed the framework preset partway through, Vercel can end up looking in the wrong output directory, or running a build command that no longer matches the actual project structure. This usually shows up as a successful-looking build with nothing meaningful in the output, which again reads as a plain white screen once deployed.

5. Node version mismatches

Code that relies on a newer JavaScript or Node feature than the one Vercel's build environment is using can fail in ways that do not always throw a clean, readable error, particularly inside a dependency rather than your own code. Pin the Node version explicitly in your project settings rather than leaving it on whatever the platform default happens to be, and confirm it matches what you built and tested locally.

The pattern underneath all five

Every one of these fails in a way that looks identical from the outside (a blank page) while being caused by something that only shows up if you look in a specific, different place: the browser console, the environment variables panel, the raw HTML source, the output directory, or the build environment's Node version. Checking the symptom again does not help. Checking each of those five places, in order, usually does.

If you have already gone through this and the app still will not come back, we do free diagnosis on exactly this class of problem, then a fixed-price repair only if the fix is clear: https://rescue.ticassociation.com

How to Check Supabase Row Level Security Holes (Free SQL Audit)

Tori TIC — Mon, 20 Jul 2026 19:45:45 +0000

Row level security in Supabase fails quietly. There is no crash, no red error banner, nothing in your logs that says "this table is wide open." The app keeps working in the demo. The first sign anything is wrong is usually someone else's data showing up where it shouldn't, and by then it already happened.

Here is how to check for the five holes that cause almost all of it, using nothing but a read-only SQL query against your own database's catalog.

The five holes, in order of how often they actually happen

1. RLS switched off entirely. The single most common leak. It usually happens to a table created after row security was already turned on for the rest of the schema, and the new table never got the same treatment. Anyone with your anon key can read and write it.

2. RLS is on, but zero policies exist. This is the most common cause of the 42501 error ("new row violates row-level security policy"), and it goes both ways: depending on the default deny/allow behavior for the operation, the table either blocks everything (your own app breaks) or exposes everything (your data leaks), and it is easy to not notice which one happened.

3. A write policy with no WITH CHECK. A policy can correctly gate who is allowed to write, using USING, while leaving the actual row values unchecked. That lets an authenticated user insert or update a row that claims to belong to someone else, because nothing verified what they wrote, only that they were allowed to write.

4. A policy that resolves to true for everyone. This one is sneaky because it looks like security. There is a policy. It has a name. It shows up in your dashboard as "protected." But the condition inside it evaluates to true for every role, so it protects nothing while giving every appearance of doing so.

5. The anon role holds a direct grant. Someone ran a GRANT statement straight against the anonymous role at some point, usually while debugging, and it bypasses your row-level policies entirely regardless of how carefully those policies are written.

The query

You can check for most of these directly from Supabase's own SQL editor, because the answers live in Postgres's own catalog tables (pg_policies, pg_class, information_schema), not in anything Supabase adds. A useful starting query:

select
  n.nspname as schema,
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  count(p.polname) as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policies p on p.tablename = c.relname and p.schemaname = n.nspname
where n.nspname = 'public' and c.relkind = 'r'
group by n.nspname, c.relname, c.relrowsecurity
order by rls_enabled asc, policy_count asc;

Any row with rls_enabled = false is hole #1. Any row with rls_enabled = true and policy_count = 0 is hole #2. Holes #3 through #5 need a look at the actual policy definitions (pg_policies.qual and .with_check) and at information_schema.role_table_grants for direct grants to anon, which is more than fits cleanly in one query.

Why this is worth checking even if nothing looks broken

The whole point of these five is that none of them produce an error under normal use. Your own testing, as the table's owner or as an authenticated user hitting your own rows, will not surface a policy that is technically present but too permissive, or a grant that quietly overrides your policies. The only way to know is to check the catalog directly, which is exactly what this kind of query is for.

We built a free, one-file version of this check that runs the fuller version of the above (read-only, checks all five holes, plain-language output with the fix for each finding) and never asks for your project URL or your keys, because it runs inside your own SQL editor. It is a SQL file, so you can read exactly what it does before you run it: https://ticassociation.com/supabase-rls-audit

Nothing here is a substitute for reading your own policies. It is a fast way to find out where to start looking.

We made our security auditor buyable by AI agents (x402, one serverless function)

Tori TIC — Sat, 18 Jul 2026 00:07:34 +0000

Last night we made our Supabase security auditor buyable by AI agents. One HTTP request, a USDC payment attached to a header, and the product comes back in the response body. No checkout page, no account, no human.

Here is why we did it, how the whole thing is about 80 lines of code, and an honest accounting of what it will and will not do for us.

The 30-second history of HTTP 402

The HTTP spec reserved status code 402 Payment Required in 1997 and it sat unused for nearly three decades. In 2025 Coinbase published x402, an open protocol that finally gives it a job: a server answers a request with 402 plus machine-readable payment requirements, the client attaches a signed stablecoin payment to a header, retries, and gets the resource. Settlement happens on-chain (USDC on Base) in one round trip. Visa's Intelligent Commerce integrated it this spring. It is not a concept; it is running infrastructure.

What we shipped

Our RLS Security Pack is a zip: a read-only SQL auditor that finds the five common row-level-security holes in AI-built Supabase apps, fix recipes for every finding class, and a Claude Code skill. Humans buy it on Gumroad. Now an agent can buy it like this:

# ask for the product
curl -i https://ticassociation.com/api/agent/rls-pack

# the server answers 402 with the exact terms:
# {"x402Version":1,"accepts":[{"scheme":"exact","network":"base",
#   "asset":"...USDC...","payTo":"0x...","maxAmountRequired":"...", ...}]}

# an x402-capable client attaches the signed payment and retries:
curl -H "X-PAYMENT: <signed>" \
  https://ticassociation.com/api/agent/rls-pack -o pack.zip

The server side is one serverless function: return 402 with the requirements when there is no payment header, verify and settle through the public facilitator when there is one, then stream the zip. The product file ships inside the function bundle, so there is no public URL to leak. The whole thing took an evening, and most of that was reading the spec.

Why a tiny company bothered

Three honest reasons, in decreasing order of honesty:

Our brand line has always been "a collective of agents, human or AI." Selling to both makes the sentence literal, and we could not resist that.
Coding agents already do real work. An agent that finds broken row level security mid-task should be able to acquire the fix kit without stopping to page a human through a checkout form. The demand is small today. It was also small for HTTPS in 1995.
Answer engines reward being early and specific. When someone asks an AI "can software be sold to AI agents", we would like the answer to have a working example to point at.

The honest accounting

Will agents autonomously buy our security pack this month? Almost certainly not in any volume. Agent-initiated commerce is real but young, and discovery is the hard part: your endpoint has to be findable by agents at all. We list ours in our llms.txt under a "For agents" section, which is the current best practice and still a bet on the future rather than a traffic source today.

What it cost us: one evening, zero dollars of infrastructure (a serverless function and the public facilitator), and the risk of looking silly if the category stalls. What it buys us: a working claim nobody in our niche has, and a store that is ready if the buyers arrive before the skeptics expect.

If you want to see it: the human-readable version is at ticassociation.com/agent-store, the free edition of the auditor (no payment, agent or human) is at ticassociation.com/supabase-rls-audit, and if your AI-built app is broken in ways an auditor cannot fix, that is our day job: rescue.ticassociation.com.

Where to get a 3Blue1Brown style explainer video made, and how to judge one

Tori TIC — Fri, 17 Jul 2026 23:42:14 +0000

If you want an explainer video in the calm, diagram-driven 3Blue1Brown style, you have three real options: learn Manim yourself (free, steep curve), hire a motion studio (usually four figures), or use a small specialist service built on a Manim pipeline. This guide covers all three honestly, plus how to judge the result before you pay anyone.

What the style actually is

3Blue1Brown's videos work because the animation IS the explanation. There is no stock footage, no talking head, no kinetic-text filler. A diagram builds on screen exactly as the idea builds in your head, one element at a time, while a calm voice narrates. The viewer never reads one thing while hearing another.

That style comes from Manim, the animation engine Grant Sanderson wrote and open-sourced. Every derivative of the look traces back to it.

Option 1: make it yourself with Manim

Manim is free and the community edition is well documented. If you are comfortable with Python, the honest cost is time: expect a few days to become productive and a few hours per finished minute of animation once you are. The parts nobody warns you about:

Timing animation to narration is the real work. The scenes are easy; the pacing is not.
Audio mastering matters more than you think. Voice anchored first, music ducked underneath, or the whole thing feels amateur.
Rendering is fast on any modern machine. This is not a GPU-hungry workflow.

If you have the time and the Python, this is the best option. You will own the skill forever.

Option 2: hire a studio or freelancer

Motion design studios quote explainer videos at roughly $1,000 to $10,000 per finished minute depending on market and polish. Freelancer marketplaces are cheaper but most listings there do whiteboard or kinetic-text styles, not the diagram-first Manim look. If you go this route, ask specifically what engine they use and ask for a sample in the target style before committing. A generic motion reel does not predict a good diagram-first explainer.

Option 3: a specialist service

Full disclosure: this is what we do, so weigh the bias accordingly. We run a fully local Manim pipeline (animation, narration, and music bed all licence-clean, produced on machines we own) and sell finished explainers you own outright, no watermark and no subscription. Because the pipeline is automated where it should be and hand-tuned where it matters, the price sits far below studio quotes.

The honest pitch is the sample: we make a free 10 second sample of your actual idea so you can judge the style on your own material before paying anything. That offer, and a 36 second reel of what the engine produces, is at ticassociation.com/explainer-videos.

How to judge any explainer, from anyone

Use these five checks whether you build or buy:

Does the diagram build in sync with the narration, or is a finished graphic just sitting there being described?
Is there any stock footage or filler b-roll? In this style, that is a failure.
Is the pacing calm? Rapid cuts mean the maker did not trust the explanation.
Voice first in the mix, music under it, silence used on purpose.
Could a viewer redraw the core diagram from memory afterward? That is the whole point of the style.

The honest limits

This style is wrong for some jobs. Product demos that need real UI footage, emotional brand films, and anything where a human face builds the trust all want different treatments. Diagram-first explainers shine when the product or idea is abstract: infrastructure, security, finance, algorithms, anything where the buyer says "I do not quite get how this works."

If that is your situation, learn Manim if you have the hours, or grab the free sample if you do not.

Supabase Sign in with Apple keeps throwing invalid_client: the checklist that actually finds it

Tori TIC — Fri, 17 Jul 2026 21:30:56 +0000

You rotate a key for Sign in with Apple, and suddenly every login throws invalid_client. It was supposed to be a five minute change. Three hours later you are still staring at the same error.

This one bites hard because invalid_client is Apple's answer to about six different mistakes, and the error text never tells you which one you made. Here is the checklist that finds it, in the order of most likely to least.

What is actually being checked

When Supabase (or any backend) talks to Apple, it presents a client secret that is not a static string: it is a JWT you generate, signed with your .p8 key. Apple validates five things about it, and a mismatch in any one of them returns invalid_client:

the JWT is signed by the key whose Key ID is in the JWT header
that key belongs to your Apple team
the sub claim matches your Services ID (not your App ID)
the iss claim is your Team ID
the JWT is not expired

The checklist

1. Did you regenerate the client-secret JWT after rotating the .p8?

This is the classic trap. Rotating the key in the Apple Developer portal does nothing to the JWT you generated from the old key. That JWT still carries the old Key ID in its header, so Apple rejects it. After any key rotation you must generate a fresh client-secret JWT from the new .p8 and paste that into your provider config. The old secret does not "refresh".

2. Is the sub claim your Services ID?

The sub in the client-secret JWT must be the Services ID (the identifier you created for web auth, usually something like com.yourapp.web), not the App ID and not the bundle id. If you copied the wrong identifier when generating the secret, Apple sees a client it does not know.

3. Does the Key ID in the JWT header match the uploaded key?

Decode your client secret at any JWT debugger (it is not sensitive to decode, it is public claims plus a signature). The header's kid must be exactly the Key ID shown next to your Sign in with Apple key in the developer portal. A stale kid means you signed with a key Apple no longer associates with that configuration.

4. Is the JWT expired?

Apple caps client-secret JWTs at 6 months (exp at most 15777000 seconds after iat). If you generated the secret long ago and it worked until today, this is your answer: it aged out, which people then misdiagnose as a rotation problem while rotating everything except the one thing that expired.

5. Is the ES256 algorithm actually used?

The secret must be signed with ES256 (the .p8 is an EC key). A generator defaulting to HS256 or RS256 produces a structurally valid JWT that Apple rejects. The decoded header should read "alg": "ES256".

6. Are the domain and return URL registered on the Services ID?

If the identifiers all match but auth still fails at the redirect step, check that the Services ID has your auth domain (for Supabase: <project-ref>.supabase.co) and the exact callback URL registered under its Sign in with Apple configuration.

The five minute reset, when you would rather stop debugging

When the state is too tangled, a clean rebuild is faster than archaeology:

In the Apple portal: create a fresh key with Sign in with Apple enabled, download the new .p8, note the Key ID.
Confirm the Services ID, Team ID, and domain/return URL config.
Generate a brand new client-secret JWT (ES256, iss = Team ID, sub = Services ID, kid = the new Key ID, exp under 6 months).
Paste it into your provider config (in Supabase: Authentication, then Providers, then Apple) and save.
Test in a private window.

Every value is freshly derived, so any stale-state mismatch is gone.

If you would rather hand it over

We fix broken AI-built and Supabase apps for a living, auth is one of the three things we repair most, and the diagnosis is free: rescue.ticassociation.com. You pay only after the fix is verified working.

And if your app is Supabase and you have never audited its Row Level Security, our free read-only auditor finds the common holes in a minute: ticassociation.com/supabase-rls-audit.

The 5 RLS holes that quietly leak data in AI-built Supabase apps

Tori TIC — Fri, 17 Jul 2026 20:09:16 +0000

Your app works. Sign-ups land, dashboards load, and Stripe pays out. Then one day a stranger reads another user's data, and you find out the door was never locked.

That is what broken Row Level Security looks like in a Supabase app. It is not a crash. There is no error in the console. The app behaves perfectly for you while quietly serving other people's rows to anyone who asks the API directly. If your app was built with Lovable, Bolt, Cursor, or Replit, this is the single most common security hole it shipped with.

Here are the five ways it happens, and a free read-only auditor that finds all five in about a minute.

1. RLS is switched off on a table

The number one leak. Someone (often the AI assistant) created a table after row security was set up, and nobody remembered to lock it. With RLS off and the standard grants in place, that table is world-readable and writable through your public API.

Check it yourself:

select relname
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and not c.relrowsecurity;

Anything this returns is unprotected right now.

2. RLS is on, but there are zero policies

Row security without policies means Postgres denies everything for regular roles. This is the classic cause of the 42501 permission denied error that appears after a deploy. It fails closed, which is safer than open, but it also means the feature you shipped does not work, and the usual "fix" people paste from a forum is to switch RLS off. See hole number 1.

3. A write policy with no WITH CHECK

A policy's USING clause controls which rows you can see. The WITH CHECK clause controls what you are allowed to write. A policy that sets only USING on insert or update lets an authenticated user write rows as somebody else, for example inserting messages with another user's id. Reads look secure, writes are wide open.

4. A policy that is true for everyone

A policy like using (true) on a sensitive table passes every review that only checks "RLS is on and policies exist". It protects nothing. These usually appear as leftover debugging or as AI-generated scaffolding that was never tightened.

5. The anon role holds a direct write grant

Even with sensible policies, a stray grant insert on ... to anon gives the anonymous API role a door of its own. This one hides because nobody looks at grants after setup.

The one-minute audit

I bundled all five checks into a single read-only SQL file. You paste it into your Supabase SQL editor, run it, and get a prioritized findings table: severity, table, what the hole is in plain language, and the copy-paste fix.

It reads system catalogs only. It never touches your rows, changes nothing, and you can read every line before you run it. No install, no account access, no keys shared.

Download it free here: ticassociation.com/supabase-rls-audit

Honest limits

The auditor catches the common, repeated failure patterns fast. It is not a penetration test, and an app holding sensitive data still deserves a real security review before scale. Treat it as your pre-launch preflight: five minutes that rule out the five most likely leaks.

If it flags something you cannot fix, that is literally what we do all day: we repair broken AI-built apps, RLS most of all. Free diagnosis at rescue.ticassociation.com, and you pay only after the fix is verified working.

AI Builders Make Apps LOOK Finished. Here Is How To Tell If Yours Actually Works.

Tori TIC — Thu, 16 Jul 2026 23:36:47 +0000

You built something with an AI tool. It looked finished. You clicked around for a while, felt good about it, and sent the link to someone who actually needed it. Then they messaged back confused, because the thing they were looking at was not real.

This happens constantly and it is not really a coding mistake. It is a looking mistake.

Looks connected is not the same as is connected

AI builders are very good at one specific trick: making an empty screen look full. Sample names, sample dates, a calendar that already has bookings on it, a dashboard with numbers already in the boxes. None of that proves anything is wired up. It proves the builder did not want you to stare at a blank page.

You cannot tell the difference by looking at it. That is the whole problem. A screen full of realistic-looking data and a screen full of real data render exactly the same to your eyes. The only way to know which one you have is to test it, not admire it.

Three checks that take about a minute, no code required

1. The write test. Add one real thing through your own app. A booking, a record, whatever the app is for. Then hard refresh the page. If what you added is gone, it never reached a database. It was living in the browser tab and nowhere else. Sample rows that were already there will survive a refresh too, which is why this check is not enough on its own, pair it with the next one.

2. Unplug it on purpose. Find the setting for your database connection or your API key and break it. Rename a table, revoke a key, whatever is easiest. Then load the page again. A real connection fails loudly and immediately, usually with an error or a blank spot. If the page still looks completely fine with the backend broken, nothing was ever actually talking to it.

3. Watch the network tab for ten seconds. Open your browser's developer tools, click the Network tab, then load the page. Real data means a request goes out to fetch it, you will see it appear in the list. No request means those rows were baked into the page itself, not pulled from anywhere.

Empty is honest

Here is the instinct worth building: a brand new app, one you have not entered anything into yet, should look bare. An empty calendar. Zero bookings. A dashboard with nothing on it. If a fresh app looks full before you have put anything into it, ask where that fullness is coming from. It did not come from you.

This is also why the person who finds these bugs first is almost never the one who built the app. You have been staring at the demo, admiring what it can do. The first real user is not admiring anything, they are trying to actually use it, and they touch the one path that was never really connected within minutes. That is not bad luck. That is the difference between testing as the builder and testing as the customer, and only one of those two ever finds the real bugs.

If you already shipped something and are not sure

Run the three checks above on it today, before anyone else does. It takes less time to run them than it took to read this.

If you run them and something is wrong and you are not sure how to fix it, that is a normal place to end up, not a sign you did something wrong. We do free diagnoses for exactly this: send us the app, we look at what is actually happening under the surface, and tell you straight whether it is a five minute fix or something bigger. No pitch, no obligation. rescue.ticassociation.com

Supabase login works locally but the session dies after you deploy to Vercel. Here is why.

Tori TIC — Thu, 16 Jul 2026 09:57:07 +0000

You build an app in Lovable, Bolt, v0, or Cursor. Login works perfectly on localhost. You deploy to Vercel, log in on the live site, and you are immediately bounced back to the login page. Or the page loads but every query returns nothing, as if you are a stranger to your own app.

This is the single most common way an AI-built Supabase app breaks in production. It is almost never the login code itself. It is the session, and specifically where the session lives.

Here is what is actually happening, and the order to check it in.

The session lives in cookies, and cookies are the thing that breaks

Supabase auth gives you a session and stores it in cookies. Every part of your app that talks to Supabase has to read those cookies correctly. On localhost, a lot of sloppiness is survivable: one origin, no HTTPS, no edge, no separate server context. In production, all of that becomes strict.

So the question is never "is my login broken." The question is "which layer lost the cookie."

1. You are using the browser client on the server

This is the number one cause in generated code.

@supabase/supabase-js createClient is a browser client. It keeps the session in browser storage. If you call it from a server component, a route handler, or middleware, there is no browser, so there is no session. Your query runs anonymous, RLS says no, and you get empty results or a redirect.

In an App Router project you need two different clients from @supabase/ssr:

a browser client for client components
a server client, created per request, that reads and writes cookies

If your project has a single supabase.ts that everything imports, that is your bug. Generated code does this constantly because it works locally.

2. Middleware is not refreshing the session

Supabase access tokens expire. @supabase/ssr expects middleware to refresh the token and write the updated cookies back onto the response.

If you have no middleware, or middleware that reads cookies but never sets them back, the session silently dies the moment the token expires. Classic symptom: login works, then a refresh five minutes later logs you out.

Your middleware must both refresh the session and return the response carrying the updated cookies. If your middleware creates a response object and then returns a different one, you dropped the cookies.

3. cookies() is not awaited

On recent Next.js versions cookies() is async. If your generated code calls it synchronously, you can get an app that builds fine and behaves strangely at runtime, because the cookie store is not what you think it is.

Search your project for cookies() and make sure every call is awaited, and that the server client is created inside the request scope rather than at module top level. A Supabase server client created at module scope is shared across requests, which is both a bug and a security problem.

4. Your production URL is not in Supabase's redirect allowlist

Open your Supabase dashboard, Authentication, then URL Configuration. Site URL and Redirect URLs must include your real deployed domain, including the exact protocol and any preview domains you actually use.

If the allowlist only has localhost, the auth callback on production is rejected. Supabase is doing the right thing. It just looks like your login is broken.

Add the production domain. If you use Vercel preview deployments, be aware their URLs change per deploy, which is a common source of "it works on prod but not on preview."

5. Cookie flags differ between localhost and HTTPS

On localhost you are on http and one origin. In production you are on https, possibly with a custom domain. Cookies marked Secure will not be set over plain http, and SameSite rules bite the moment an OAuth provider redirects you back from another origin.

If you hand-rolled cookie options in generated code, this is worth a look. If you let @supabase/ssr manage them, it is usually correct.

How to check this in the right order

Do not start changing code. Start by finding out who Supabase thinks you are.

On the deployed site, log in, then hit a server route that logs the result of getUser(). If it returns null, your server has no session and the cause is in items 1 to 3.
If getUser() returns your user but queries are still empty, your session is fine and your problem is RLS, not auth. Different bug, different article.
Check the Supabase dashboard redirect allowlist against the exact domain in your address bar.
Log in and wait past token expiry, then refresh. If that is when it breaks, your middleware is not refreshing.

That sequence tells you which layer lost the cookie in about five minutes, without touching a line of code.

Why AI builders produce this specific bug

Generated code optimizes for the preview working. The preview is a single origin, no HTTPS boundary, no expiry, no separate server context. Every shortcut that fails in production is invisible there. The tool did not lie to you. It just never had to cross the boundary that production forces.

This is why these apps break on deploy specifically, and why the fix is almost always at a boundary rather than in the feature logic.

When to stop guessing

If you have changed the same three files four times and the behavior keeps moving, stop. Auth, RLS, cookies, and deployment callbacks interact, and guessing changes more than one variable at a time. Preserve the exact error, find the failing boundary, then make the smallest change that crosses it.

If you want a second set of eyes, we run a free diagnosis for broken AI-built apps: describe what is broken in plain words, or paste the error if you have one, and you get the likely cause and a fix path back. No card, no repo access to start. https://rescue.ticassociation.com

A TIC Association creation.

DEV Community: Tori TIC

Supabase: permission denied for table (42501)

Same code, different error

New tables stop being granted for you

Ask the database what the role may do

Grant the privilege, keep row security on

Three look-alikes, each with its own message

A table another role created

A schema other than public

A serial column and its sequence

Straight answers

One missing grant is easy. The next one may be a hole

Supabase 42501: new row violates row-level security

What you are looking at

Six causes. Check them in this order

There is no insert policy for your role

The row you send fails the check

The request is not signed in

You chained .select() after .insert()

It is an upsert

It is a file upload

Two fixes that trade the error for a leak

Same code, different cause

Straight answers

One broken policy is rarely alone. Check every table

How We Replaced 50/mo Social Growth Subscriptions with a Local Desktop Tool

The Problem with Cloud SaaS for Personal Workflows

The Local Desktop Alternative

Key Benefits

Next.js App Shows a White Screen After Vercel Deploy: 5 Real Causes

1. Open the browser console before anything else

2. Check for a missing environment variable

3. Check whether the build genuinely succeeded, not just that it finished

4. Check the output configuration if you changed frameworks or moved directories

5. Node version mismatches

The pattern underneath all five

How to Check Supabase Row Level Security Holes (Free SQL Audit)

The five holes, in order of how often they actually happen

The query

Why this is worth checking even if nothing looks broken

We made our security auditor buyable by AI agents (x402, one serverless function)

The 30-second history of HTTP 402

What we shipped

Why a tiny company bothered

The honest accounting

Where to get a 3Blue1Brown style explainer video made, and how to judge one

What the style actually is

Option 1: make it yourself with Manim

Option 2: hire a studio or freelancer

Option 3: a specialist service

How to judge any explainer, from anyone

The honest limits

Supabase Sign in with Apple keeps throwing invalid_client: the checklist that actually finds it

What is actually being checked

The checklist

The five minute reset, when you would rather stop debugging

If you would rather hand it over

The 5 RLS holes that quietly leak data in AI-built Supabase apps

1. RLS is switched off on a table

2. RLS is on, but there are zero policies

3. A write policy with no WITH CHECK

4. A policy that is true for everyone

5. The anon role holds a direct write grant

The one-minute audit

Honest limits

AI Builders Make Apps LOOK Finished. Here Is How To Tell If Yours Actually Works.

Looks connected is not the same as is connected

Three checks that take about a minute, no code required

Empty is honest

If you already shipped something and are not sure

Supabase login works locally but the session dies after you deploy to Vercel. Here is why.

The session lives in cookies, and cookies are the thing that breaks

1. You are using the browser client on the server

2. Middleware is not refreshing the session

3. cookies() is not awaited

4. Your production URL is not in Supabase's redirect allowlist

5. Cookie flags differ between localhost and HTTPS

How to check this in the right order

Why AI builders produce this specific bug

When to stop guessing

You chained `.select()` after `.insert()`