not sure how to use new api secret key
hey folks
i disabled the legacy api keys and created the new api keys, so now i have a publishable key and a secret key named default. but i was a little confused about using the secret key, as it doesn't appear to have a reserved name like the old service role key did. in my local .env file i created a new variable SB_SECRET_KEY and set it equal to the secret API key copied from the supabase dashboard. then i set this new secret using the command line, so now i see it in the edge function secrets. but this didn't feel like the right way to use it - it seems like i just created a new edge function secret. or is that really what we're supposed to do? i did the same for the publishable key, that is i made a new edge function secret SB_PUBLISHABLE_KEY
thanks!
8 Replies
Theres really no need to pass the secret key to your edge functions if you don't need it. No?
You should be fine with the publishable key
some of my edge functions modify tables that are protected from public access by RLS (hence i need administrative privilege, or at least that is my understanding)
If you are testing your edge functions locally you don't need the secret key since the local project uses a different key that it's showed to you when starting local project
Firs thing to note is that if you have gone and rotated your keys to secret/publishable then
SUPABASE_ANON_KEYshould be equal to publishable and SUPABASE_SERVICE_ROLE_KEY should be equal to the secret key. and those will still be available to your edge function
the way to confirm this is to create a quick test function in the dashboard where you do console.log(Deno.env.get("<relevant key>") and you should see that these match up with publishable/secret API keysthanks! good to know i can continue using SUPABASE_ANON_KEY and SUPABASE_SERVICE_ROLE_KEY if needed. is it required that i use these old names, or can i make new secrets named "SB_PUBLISHABLE_KEY" and "SB_SECRET_KEY" with the key values? does supabase detect that the value i set to the secret and publishable key is equal to the api keys it gave me (and hence knows what privileges to assign these keys)? (this is what i did and it seems like it is working but it is also possible i just don't know what is going on lol).
1) You don't have to use these old names (i expect at some point supabase will change those anyway but they have been kept for now to be backwards compatible) 2) I assume that when you use those keys you will be doing so via setting them in the client with their values at which point the name you reference should not matter
i set them using supabase secrets set --env-file .env (where the .env file has SB_SECRET_KEY="key copied from supabase api keys dashboard"
okay, i think i get it now. i can store the keys in whatever environmental variable i want for easy access. the name of those variables doesn't matter. only their value matters. because the apiKey header, for example, just wants you to give it the key value. it doesn't care about the name itself. the name is just an easy way of referencing the key value. the same is true in my backend with the secret key: i pass the key directly into the createClient function, the environmental variable is just a way to get the key value. basically, supabase just creates the keys, and it is up to me how i store them and reference them in my code. if i want i can use supabase's reserved env variables but i don't have to, i could make my own secrets to store those values.
thank you for your help 🙂
yeah pretty much & you're welcome!