LOCAL setup db error: No suitable key or wrong key type
Hi, I'm experiencing an issue in local setup where trying to access my supabase table from my client returns with the error
{"code": "PGRST301", "details": null, "hint": null, "message": "No suitable key or wrong key type"}. This error does not occur in Production.
When setting up my local, I've already followed the appropriate steps like setting up Docker, running db pull && db migration up to recreate my production schema in my local.
In my table, I've already enabled RLS to enable SELECT on my table for authenticated users with the 'using' condition as '(( SELECT auth.uid() AS uid) = user_id)'.
From my client, I am calling my table like so:
try {
const { data, error } = await supabase.from("table").select();
if (error) throw error;
return data;
} catch (e) {
console.log(e);
}
Any help would be appreciated. Thank you
18 Replies
What is your cli version? Which key are you using in your createClient call?
Hey @inder , I'm on v2.48.3.
My createClient call is using:
Local API url retrieved from 'supabase status', and the Anon key
-----
const supabaseUrl = process.env.EXPO_PUBLIC_SUPABASE_URL as string
const supabaseAnonKey = process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY as string
export const supabase = createClient<Database>(supabaseUrl, supabaseAnonKey, {
auth: {
storage: AsyncStorage,
autoRefreshToken: true,
persistSession: true,
detectSessionInUrl: false,
},
})
Are you using clerk? https://discord.com/channels/839993398554656828/1428462874531201105
If not have you enabled signing_keys in config.toml?
I am not using Clerk.
I have not enabled signing_keys.
I just tried enabling it, but the error persists.
In my config.toml, I've uncommented this line:
signing_keys_path = "./signing_keys.json"
I guess it's probably failing because i don't have signing_keys.json in my project. Are you able to point me to where I can set this up? Another question is why would this fail locally and not in production? (Sorry, I am a beginner at this)
No this isn't necessary just wanted to know if you have it enabled. This needs a separate keys file to be generated. You can disable it if you're not using it
You can try installing the latest version of cli and try with that.
Use
npx. Its easier to manage cli versionsHi @inder, I've updated my cli version to 2.51.0, but the error persists. As you shared above, it's likely due to a JWT issue. One thing to note probably is that when my client calls the table, the user might not be authenticated. If I understand correctly, the assuming role would be
anon . I've tried amending the RLS to allow anon roles for SELECT access, or even disabled RLS completely for that table, but the issue still persists.I tried with a new project on my end and didn't face this issue.
Try taking down containers, remove supabase volumes and then start stack again.
Also are you using the old anon key or the new publishable key? Both should work, just trying to reproduce the same issue locally
I am using the old anon key, the one taken from project > settings > API Keys > Legacy API Keys
Are you using the one from cloud locally?
local supabase has its own anon key
Run
npx supabase status -o env | grep ANON_KEY
You will get output like this. use the key value
That was the issue! I didn't know local uses its own anon key.. Thank you so much for your help.
Yeah. Also just a heads up service role key, db password everything is different for local supabase.
I am next facing an issue which I believe should be a simple thing I am missing. I am now getting a permission denied error when trying to run select on my table.:
LOG {"code": "42501", "details": null, "hint": null, "message": "permission denied for table ..."}
What I don't understand is being denied permission even when disabling RLS, or setting the RLS's target roles to 'public'. Is this related to having different keys on local once again?
Below is my RLS:
alter policy "Enable users to view their own data only"
on "public"."table"
to anon, authenticated, postgres
using (
(( SELECT auth.uid() AS uid) = user_id)
);
Disabling RLS should have worked.
What if you simply set it to true inside using block
Currently, you're checking for auth.uid() even for anon user. if your goal is complete
SELECT access, this won't work
For users who should only view their own data, you can simply set the policy to authenticated role only
Tried disabling again, or amending policy to
using ( true ); , but still getting permission denied. For my particular use case, data in this table can be accessed by both anon users (not logged in yet) and authenticated users.Try using service role key. That bypasses RLS
If that doesn't work, then there is some issue with grants
I've managed to resolve this. I noticed that in my migration scripts, there are a bunch of
revoke statements that basically removes grants from my anon, authenticated and service_role roles. I've commented those out which fixed the issue.
If I want these migration scripts to be updated in prod, can I simply do a db push? I was wondering if simply pushing changes in old migration scripts to prod is considered best practice, or is there a better way?
Thanks!Can you create another post for this specific issue? I have noticed some other users coming up with the same issue. Might help someone else in the future
Sure @inder , I've created it here https://discord.com/channels/839993398554656828/1430064643535016057