Security concerns regarding Table Views

Hello! I have a question regarding app table views and how permissions come into play.

From what I understand, views only seem to grab any and all data regardless of user permissions and object ownership. View permissions seem to only apply to the ability to grab all that data, or none at all. At least, that’s what I’ve notice when toying with table views with my app.

Though the table view system is a handy solution to one of my applications, the lack of permissions of retrieved objects is unfortunately not very useful as multiple users would be using it to view contact data gathered from multiple related tables.

My big question here is if there was any way to be able to manually check the calling user against the owner id from the primary object?
Or, perhaps the ability to create a master view condition like so:

ownerId = User.objectId

Where the User is the “Users” table object representing the user invoking the retrieve call, or something similar?

Thank you in advance for any advice

Hello, @Nathan_Cousins.

For View, you can configure permissions for all RETRIEVE objects (this can be done both for individual users and for roles). You can also customize the visibility for the columns. This way you can hide some columns for certain roles.

You need to get the record, and then for the record execute find in the Users table by objectId = 'owner-id-from-record'

Regards, Nikita.

Hi @Nikita,

I have the Retrieve role permissions disabled for all tables related to the View, only allowing Retrieve using ownership permissions. On the View, I have Retrieve role permissions enabled, as disabling it rejects the Retrieve call on the View altogether.

Is what you’re suggesting I do is make the client call Retrieve on the View to get the records, then filter the records out by testing against ownerId? Maybe I’m misunderstanding but since I’m having the client app make the API call I wouldn’t feel comfortable doing that, I would much prefer the security be handled serverside, otherwise that data is vulnerable to anyone who is able to intercept the fetched data or invoke api calls manually.

It would really be nice if Views took the calling user’s permissions for those tables into account, which seems expected at least to me. Since I need that data to be private using ownership permissions, I can modify my app to make standard retrieve calls against the tables manually, though it would have been nice to use a View as an elegant solution.

Thanks

Hello @Nathan_Cousins

I have created an internal ticket BKNDLSS-26168 to add owner policy support for views. I think the feature will be released during the next 7-10 days

Hi @sergey.kuk,
Awesome! With the extra security features I am excited to be able to use Views more in the near future

Thanks again,

Nate

@sergey.kuk : does this discussion mean that a view is ignoring all access permissions which have been declared for the underlying tables?

My understanding is that View would be treated as a separate entity and thus would ignore underlying table permissions. @sergey.kuk please confirm.

Hello guys,

My understanding is that View would be treated as a separate entity and thus would ignore underlying table permissions.

Yes, it is true. You should consider a View as an independent readonly table

We expect that finally, permissions for Views will be the same as for tables including object acl for users

Hi, @Klaas_Klever

We’ve just updated cloud servers with a fix for the issue you described above. We have added owner policy permissions. Please note that for Data Views owner policy permission includes only one Retrieve permission. I would also like to draw your attention to the fact that Data Views are an independent read-only table and these permissions ignore the underlying table permissions.

Regards,
Marina

1 Like