i got an email that this feature will be removed.
does this mean i cant set rules to individual users for specific records?
Hi Mohammad,
That’s correct, once the ObjectACL feature is removed, you’d be able to set rules for the individual users only through custom roles.
Regards,
Mark
But its impossible with rules
the rule need to be for specific records… how can we do that
One option is to add afterFind event handler and remove the objects that the user should not see from the response.
That is just double query everything…
And the big issue is you are breaking the real time events now.
All the users will get update event when a record is changed in the table.
That makes real time useless.
You guys will break my app for good with this change
Please elaborate on the following:
- double query - where and how?
- update event for all users - how?
1- I have to make a second check to filter the records on the server before sending it to the client. Where before the server will automatically only serve the records with correct ACL
2- all users will have the right to listen to update events. All they need to do is open the browser console and add a listener without a client side filter.
Could you describe the actual use-case where the same table has different permissions for different users? I am not asking for technical details, but more from the app’s business perspective.
Thanks,
Mark
Messages table
Every message have a sender (owner) and receiver.
Only these two users have the right to listen to the record changes and only the receiver have the right to delete the record.
Is this scenario possible without object ACL?
Hi @mohammad_altoiher !
Unfortunatelly, to keep your code in working state you should add afterFind handler and perform security check in your code.
We understand that you do not want to do it in this way. According to our research there only are few apps heavily use object ACL feature. Further support of object ACL will restrict us with implementation of new features for Data Service and also will make data requests slower.
Due to this facts and possible benefits we decided to deprecate and remove this feature.
Again - sorry for inconvenience, but you should make appropriate changes to your code before first Monday of April to keep your app in working state.
Regards, Andriy
its not the change in my code im worried about
its the problem that we will have with security.
with your approach. how can i know if the user is trying to listing to unauthorized changes to a table or a normal intended query?
just because your users don’t care about this level of security doesn’t make it less important.
Correct me if I am wrong, my thinking is that if the objects in the Messages table have a column that indicates who the messages are from and to, then you should be able to filter out the objects that the user should not see.
But isn’t the filter will run on all the requests (real-time, codeless)?
and will this filter also prevent the user from getting any update or delete events for the table?
Let’s separate the questions. For RT, you’d need to add a where clause so the user would be getting only the messages targeted at that user. To do that, the recommended approach is to add to and from columns to the Messages table. The columns would contain objectId of the sender and recipient. When you subscribe to receive messages, you’d specify the condition of
to = 'objectId-of-the-current-user'
This would cover the RT part. For non-RT retrieval of the objects, you’d use the afterFind event handler which will remove any objects from the response that do not belong to the user.
Regards,
Mark
The main point is the condition is defined on the client .
what prevent any malicious user to open the console and subscribe with no condition?
With ACL i don’t care what the malicious user is trying to do on his device or browser. he simply cant listing to anything i did not allow him to access.
This scenario can also be prevented by using RT events for Cloud Code:
https://backendless.com/docs/js/rt_cloud_code___business_logic.html
When a client connects your Cloud Code can send a message to the client requiring it to validate itself. That validation may be as simple as sending user-token for the current season. If the token is valid, you know the client is legit. Otherwise, disconnect the client.
Yes, it is more work, but the point is all of this is possible without ACL
I didn’t understand
the user is a normal user with user-token. there is no issue here.
but when he trying to listen to objects that he shouldn’t be accessing, here is the problem. he is still a legit user in the system. and i want him to connect to RT but with limited access
If it a normal user, they will not be able to get anyone else’s messages with the approach I described. My previous post was in the response to your message about malicious user.
You mean this approach?
on what event in cloud code i should add this?