s
Sure
So basically every time something get's inserted into my db, it triggers a dm to a user in discord
And I don't want people spamming submit with edited supabase auth credentials
And being able to dm spam through my bot
I could do this through my bot
Have it check the id and if there are to many delete some
But I'd rather have the db handle it for me
s
I'm not sure what you mean by spamming submit with edited supabase auth credentials
s
I've seen multiple threads that the devs plan to add rate limiting soon
supabase.auth.session().user.user_metadata.provider_id = personYouWantToSpamDiscordID
Then spam the submit button which uses supabase.js to insert a row into my db
Which triggers a function hook to my discord bot which dm's that id
s
You are definitely missing some further detail in your explanation
I don't know what exactly you are missing but the supabase.auth.session() only holds information for that logged in user
How would that allow anyone to spam your bot?
s
> supabase.auth.session().user.user_metadata > Object { avatar_url: "https://cdn.discordapp.com/avatars/633434170596786186/85b80f9321da4fb560380ce01c6d1672.png", full_name: "sudo killall windows", provider_id: "633434170596786186" } > > supabase.auth.session().user.user_metadata.full_name = "not sudo" > "not sudo" > supabase.auth.session().user.user_metadata > Object { avatar_url: "https://cdn.discordapp.com/avatars/633434170596786186/85b80f9321da4fb560380ce01c6d1672.png", full_name: "not sudo", provider_id: "633434170596786186" } > > ​
s
Isn't this behind a user login?
s
Because a function hook calls my bot
Yup. Sign in with discord
Through supabase auth
s
You can't actually update that data that way, so not sure how this would be an issue
I think there are some assumptions here that don't actually work the way you are assuming
s
When I make a new row one of the items is the Discord Id, and it get's it from supabase auth session
s
supabase.auth.session() is read only
s
Well It let me modify it
s
That data will not be saved in the database
You should be reading data from the database using the currently logged in user's information
Not using the supabase.auth.session() function
s
Ah
Got my head stuck in do it on the client world lol
s
If you are passing this data along then this can definitely be spammed
No never do stuff like that in the client world
Hence why I mention RLS to you earlier, it can save you a world of pain
s
all hail the RLS gods
s
lol
Remember inside of functions you can write sql queries
so you could do a select based on the
auth.id()
to get the user information to get the
user_metadata.provider_id
This is probably stored in the db under a jsonb column type, so you would access it using
raw_user_meta_data->>'provider_id'
Let me know how you get on tomorrow, I'm going bed now, it's late here.
s
GN!
I just wish I could log in a RLS query so I could see what I was dealing with
well... i could make a logs table