Hello, I am trying to update a supabase table. The table has realtime “on” and proper RLS.
In Weweb, the current values that need to be change populate as expected in the form. After submit, the object that is send to supabase seems correct but no update takes place.
What I am missing? Any pointers would be helpfull.
Here is a summary to make it clearer:
I’d suggest looking at the Network tab in Chrome Dev Tools, send it here if possible, so we can see what’s going on. You can also check the Supabase error logs.
Does it work when you turn RLS off entirely? Meaning you disable the RLS at all, not just policies.
Hi, I am not sure on how to turn off RLS entirely but when I remove the policies I dont get any data on the app.
It works when I disable RLS??? Is this a nomal behaviour?
I see this being a recurrent issue, I’ve also been debugging this with @greger in this thread and on a call.
@Alexis is this something you might be able to resolve? It’s basically the same pattern.
Maybe double check your RLS rules, what did you type inside the RLS ?
hi @Rusty, I had similar issue. But have just done a test with fresh WW app and SB credentials/environment, and it worked fine 
also with policies auth =user_id.
Suggestions:
If you could share the policy we might be able to help you
I am having exactly the same issue: with RLS activated, the workflow to update a supabase table finishes succesfully, but the table is not updated. When I deactivate RLS, it works. I’m having two policies set up: one enables everything for authenticated users only and the other enables read access for all users. Does anyone have an idea how to solve this?
Couple of caveats, a) I’m very new to this, b) I have very little idea how all this works, so this is probably a stupid workaround, but it did work.
I had exactly the same set up as you. Same issue seeing success on test but no table update and seeing an updated table when RLS was disabled.
I added another column to my table called user_id of type uuid and then set the default value to auth.uid. This returns a user’s ID when rows are added. The way this is working now is that every time I update or insert, (I added an insert policy as well), a new row, the user_id is automatically updated and it works.
This had the added bonus that I can now gate users based on their authenticated emails. I guess this might be the bones of multi tenanted a database?
Thanks for your reponse. Since I want all authenticated users to be able to update all Supabase records, this won’t work for me (as I understand you, in your case, a user can only update those rows that he created, right?)
@Broberto, @Alexis have you found a solution to this problem in the meantime? I’m not able to update a record in Supabase if RLS is activated, even though my tables have the correct policies in place:
SELECT → all users (public) (I also tried anon & authenticated - didn’t work either)
INSERT → authenticated users
UPDATE → authenticated users
I’m able to perform SELECT and INSERT with RLS enabled, but UPDATE does not work! As you can see, I also added SELECT for everyone (I read in the other thread that this is required).
In the WeWeb debugger, the Supabase Update action is performed succesful, but when I check the table in Supabase, the update has not been done.
How did you guys solve this problem?
No worries. So, yes, a user can only update a record they inserted because they will only be able to see records they created. This suits my use case at the moment but I can see the benefits of what you are trying to do and it could be useful for me as well. In my case it would be that if someone in a company creates a record, someone else in that same company would be able to update that record.
I’ll work on that and see if I can get a result.
I think the resolution lies within roles and permissions. This might help: Supabase authentication | WeWeb documentation
I don’t think that is the case. Roles and permissions would make sense if I would only want specific user groups to perform specific tasks. I want all authenticated users to perform any update queries on the Supabase table, so there is no dedicated roles and permissions required.
In case someone else has the same issue, the solution is pretty simple actually: when setting up the UPDATE policy for authenticated users, you need to make sure that the USING expression evaluates to true as well - then everything works as expected!
I was able to make it work by creating a SELECT policy with same conditions, in addition to the UPDATE and INSERT
