Using Firebase Auth with Supabase Storage
Trying to upload to Storage fails because my Firebase UID (text) is being inserted into storage.objects.owner_id (uuid), causing:
Is there a workaround for this?
10 Replies
owner_id is text
Could it be your RLS policy is using auth.uid()?
Storage is supposed to take your sub claim and if UUID put in both owner (UUID) and owner_id(Text). If it is text then owner should be null and owner_id should be the text value.
If it is RLS then use auth.jwt()->>'sub' instead.
Thank you for the quick follow-up.
I misspoke, I apologize. I meant to reference
storage.objects.owner, not storage.objects.owner_id.
My RLS policies don’t use auth.uid(). I temporarily created a new policy with:
Target roles: authenticated
WITH CHECK expression: (bucket_id = 'bucket-name'::text)
I seem to still be getting the same error.Is this a new Supabase instance?
Relatively. I believe it was created around May this year.
I would upgrade, but I think the owner_id column was before that.
Upgrade Postgres version.
I assume this is not production?
I don't see any issue in storage on this:
https://github.com/supabase/storage/issues?q=is%3Aissue%20state%3Aclosed%20owner%20uuid
Others do this with other auth systems with text sub claims (like Clerk) and I assume Firebase. And that is why owner_id was created.
It is production, so I’d like to do it safely if there are any risks with upgrading.
Yeah, I hear you - it should work, right? I’ve double-checked my policies, so I don’t really know what else could be causing it.
Yes it should work. The change was made awhile back...
https://github.com/supabase/storage/pull/340
GitHub
feat: deprecate owner column in favour of owner_id by fenos · Pull...
What kind of change does this PR introduce?
feature
What is the new behavior?
Deprecate owner column in favor of owner_id
owner_id is now of type text
Write to both columns if the owner is uuid, o...
Check with the table UI if schema storage table objects has an owner_id column. Probably a waste of time but just in case.
I don't think you should have to upgrade to get it to work from May.
Upgrading, especially if from 15 to 17 carries some risk of down time to clean up. Also right now there have been more upgrade lockups so I would not recommend it for production right now.
Especially as upgrading is not likely the issue.
If it where a brand new problem with recent storage server updates (which are shared not part of your instance) I would expect at least a few complaints here or github as several auth systems use text sub claims.
Do you have any sort of triggers YOU added to storage?
Ah! You got it.
While experimenting with a workaround for handling Firebase user IDs in Storage, I had added a trigger to set the
owner field, which of course doesn't work, because I was mapping incompatible types.
Thank you very much for debugging this with me, and thank you again for the quick response time.