If anyone can explain, I’m listening!
I’m looking to insert a row into a Supabase table. The rsl policy is set to “public” (I want everyone to be able to insert. It works perfectly with Weweb’s API rest plugin, but it’s impossible to make it work directly with weweb (see photo).
Thanks for any comments or answers
Can you show us how things are setup in Supabase for the table requests?
There might also be additional information in the cause part of the error message you shared in your first screenshot
You gotta watch out for what you’re allowing the users to do within RLS, as sometimes it is easy to give them rights to something else. Now you’re trying to INSERT, so check for insert, and if possible, send us the policy. It should be like this I think, you always have to return either true/false, no matter what your conditional logic looks like.
Also, if you have some other policies, it might be conflicting with them, so make sure you don’t have a conflict where you are limiting INSERT and also allowing INSERT in the current one.
Try removing it (the anon) completely. leave the Target roles blank) It might be that you’re accessing from auth account and trying to insert? See what I’m doing.
It changes nothing
Do you also use Supabase Auth?
Yes
As I thought, you also need to enable SELECT to everyone. I tried it on my DB and it should work.
Thank you very much!
Does this mean that everyone can also read the base?
Yes, the answer to why is in this thread, it is not optimal, but it is how the plugin works underneath.
@Alexis you might want to check the { returning: 'minimal' }) for your Supabase Plugin Update, it’s mentioned as a thing that could solve the issue.
Hi folks, I have the same issue and I’ve read all the information in this thread and my question is how to implement this returning: “minimal” with Weweb because I definitely don’t want to grant SELECT policy for the anonymous visitors of my webpage. Could someone help with it?
Hey @Maro 
It’s a current limitation of the Supabase plugin in WeWeb because we do an automatic SELECT after an INSERT. The tech team is aware and will look to improve this.
In the meantime, you can use our REST API plugin to make your INSERT call to Supabase. If you’re not sure where to find the API endpoints to make the call in Supabase, here’s a video to another user that might help.
If you get stuck, don’t hesitate to create a new topic with a short video or some screenshots showing us how things are setup on the Supabase and WeWeb side of things. We’ll do our best to help out 
But using the rest api plugin makes the api key of supabase viewable to the public or not? So if yes you can’t use it at all for sensitive actions or data…
Supabase provide two separate keys. One is private, the other one is public.
In our supabase plugin we ask for both.
The private one allow to connect to your supabase as an administrator (like accessing to the supabase back office), it’s used in the editor to analyse your instance and improve the user experience, it make us able to display your table list for example. The private key is never embed inside the published website of course.
The public one is used to connect to your supabase as an user/consumer. This one is made to be embed in a front end.
If you choose to use the rest api plugin you will use the public one. Si there is no security concern.
just checked it: the public key is in the frontend.
So how are rest api supposed to use with having the api-key public?
Within your user session you have the auth key, which you pass as authorization. This auth key is then used by RLS to check the permissions. With the APIkey, without an authenticated auth key, you can’t do anything if your RLS is set up properly, so it doesn’t matter if it’s exposed. You can’t expose the private key, that’s the only one that is really secret.
If your users end up leaking their auth keys, then it’s a problem at the users level. So yeah, that’s how it works in a nutshell.
A test you can do, is set up RLS on a table and hit it with REST, you’ll se that you’re not gonna be able to. You need to pass auth as well.
BTW the weweb plugin does not get any results any more but the rest api does no matter what I set in policies… and just use the public key not the service_role key…
So just to summarize:
To get the weweb plugin to work right and at the maximum of safety it is:
So everyone with the public key can select everything, which is a big problem. I want to handle sensitive Data.
On Top a Bug where we can select with public key with REST no matter what policy is set.
I hope I am the stupid one and we will find a solution…
This was my bad I submitted the bearer token with the service role… no bug
Can you show us your api call?
You have it there. You’re passing authorization bearer token - thus authenticating the user.
