#b33fb0n3_api

1 messages ¡ Page 1 of 1 (latest)

cedar cradleBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1263095257310957589

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

timid cobalt
#

I'm sorry I don't understand the question. What are you trying to do?

surreal estuary
timid cobalt
#

Got it, none of that data is exposed via the API I'm afraid

#

Persons API is irrelevant in this context (it's for KYC stuff for the account, not Dashboard users)

surreal estuary
# timid cobalt Got it, none of that data is exposed via the API I'm afraid

ohhh :/ ok
Do you know any resources, where I can find such data schema? I tried to find some online and found rbac data schemas, but they are mostly just one user has multiple roles, that has multiple permissions. But there is nothing about "User A is allowed to create xY in that specific account"

timid cobalt
#

Sounds like you're describing RLS really? Database concept that prohibits row access to specific users

#

Otherwise you create middleware in your API that checks if user X has read/write for account Y

surreal estuary
#

So it's not about row level security, more about object level security

timid cobalt
#

Well normally a DB row is an API object. But that's an implementation detail really

surreal estuary
#

but I am afraid that does not exists :/