• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
business logic in the livecide application
Dear Team,

livecloud doesn't support user permissions by default. 
So I want to write it in livecode. 

for example. i want to make rbac.
1. Role: Manager
2. Role: employee

only the employee role can see the employee table or
only the managerrole can see the manager table.
my assumption is if someone gets or knows the recordID then they can freely do it to search.

is it safe if I write rabc logic directly in livecode?
do you have an example to make rbac in livecloud?

if I use parseplatform.org I write it in cloudcode.

To start adding user permissions for RBAC, create a key in the cdbUsers table of your project to store the role of each user.

It's safe to write the RBAC logic in LiveCode. With this approach, you would check if the user's role (which can be retrieved with cdb_readUserAccount) and the table matches before making the call.

To create RBAC with LiveCloud, you could create a table to store individual permissions for each role. You would then query the user's role in that table to retrieve the values for each permission.


--Key added to cdbUsers table: "role"
--Table "permissions" created with the following keys:

local tUserA, tOutputA

put cdb_readUserAccount("cora@fakeemail.com",,false) into tUserA
put tUserA[the keys of tUserA] into tUserA
put cdb_query("role","=",tUserA["role"],"permissions","cloud","recordData") into tOutputA
put tOutputA[the keys of tOutputA] into tOutputA
if tOutputA["permission1"] is true then
    --allow action
    answer "You do not have access to this table."
end if
thank you for your response
I'm worried about writing business logic from the client side. If someone knows the ID records then my application is easy to "hack".
I usually write business logic from the backend server side.
can you tell me practical steps to protect business logic in livecode applications. besides using "set the password"

thank you
Hi Miyaa,

Security is of the utmost importance when working with data in the cloud. Knowing a given recordID is not enough to access your data. The CanelaDB libraries can not be opened in someone else's application because there is an authentication key check unique to your company.

Next, there is the authentication to access data in the cloud (email and password). You would not include those credentials in your shipping application. Each client has their email and password to access a given record. Each user of your app has a unique authentication key.

You never need to store recordIDs in your application. You would get those in real-time via queries or cdb_list() calls.

Your data locally and in the cloud is encrypted. Your data is encrypted with unique values.

RecordIDs are UUIDs. And thus, they are considered to be very unlikely to guess.

Writing logic to determine roles and permissions can be done as Linda provided. But, our ultimate goal is to simplify as many backend tasks as possible. We will eventually release a APIs to help you manage this in the backend. It will make developing apps a lot easier.

We managed to work out many of the details and have a good start on this topic. Alas, we are not done and more work is needed before we can release this feature.

Forum Jump:

Users browsing this thread: 1 Guest(s)