Has it ever been considered to make it that filtering data to be secure so the filtering is done before it downloads the data to the device? Seems like trying to institute multiple row owners (or having to rely on google sheets array to achieve that) is much more difficult than how easy it is to create and manage apps to display the right data using the filtering. I regularly run into issues where I question the tradeoff of using glide for ease vs the security risks (vs utilizing multiple row owners) and it just seems like it would be magical if filtering didn’t have this security risk. Just wanted to throw it out there…
The row owner column is a filter that will prevent downloading the data that is not marked… I have no idea what you are requesting.
Based on this:
Filtering and Visibility conditions are NOT security features. When you hide tabs, components, or filter out items in lists, the data is still accessible on the user’s device. Read our Security Guide to learn how to protect sensitive data.
What I’m saying is that filtering and visibility is so amazingly simple to use, it’s one of the magical parts of making glide apps. But it’s a security concern as stated above. The workaround seems to be multiple row owners, only achieved by one of these 2 methods:
You may want multiple owners for certain rows. With Row Owners, there are two ways of doing this:
If your app uses Google Sheets as its data source, you can use an Array Column containing multiple emails or multiple roles, and assign that as the Row Owner. Once this column is a Row Owner, each of the emails or roles in the array will be able to access the row’s data. You can also configure this column as the as the role source column for user profiles.
To make an Array Column in Google Sheets, create columns with the same name and then number each one sequentially. It’s important that each column has the same exact text and then the next number in each column. For example, Owner 1, Owner 2, and Owner 3.
You can also make more than one column a row owner column. For example, in the table below, there is a second email column that contains an administrator’s email in each row. This way, each individual user is a row owner for their row, and the administrator is also a row owner. This approach will work for any data source that is linked to your app if you need to assign multiple emails as the row owner.
However, A) I don’t want to use google sheets, and B), making multiple row owners adds significant complexity. In one of my recent scenarios, I can easily just create an “organization ID” that multiple users are attached to. Then in another table, I am storing records for all organizations. The app works beautifully when I use the filter data feature to just show items where organization ID matches the signed in user’s Organization ID. But that’s unsecure because all records are actually being downloaded to the device. If I were to go the route of using multiple row owners AND stay with glide tables, I have to find a way to dynamically add every person in the organization to every row in the table. Seems far more complicated than if filtering/visibility had an option to not download all records to the device, then filter. Unless I’m missing something.
The thing is that filtering by its nature is dynamic, which means that all data must first be available (downloaded) before the filter is applied. So it’s too late to make it secure.
The correct approach is to use row owners, and roles as row owners where applicable. Sure it might seem a little complicated and takes a while to understand how to use it correctly. But making things secure sometimes takes a little extra care and effort. That’s why Cyber Security specialists get paid the big bucks 
1 Like
yep… to filter data, you have to download it first… so your request makes no sense.
Unless you use Google Sheets like I do… then you can create a filter in the app and fetch data with the filter parameters in the url
Thanks @Darren_Murphy I get that 
and yes, @Uzo by the nature of how filtering works in glide today, I understand that. And I already built the whole thing in glide tables and didn’t want to migrate back to google sheets (plus there seems to be some added benefits to using glide tables—data all in one place, a tad faster, etc). So I was just saying if there was a way to utilize some way of performing a filter function server side before the data downloads, that’d be awesome.
So in my scenario, where I want a bunch of people in an organization posting things that I don’t want accessible by others in a different organization, how could I securely achieve it with glide tables? Keeping in mind there’s not a finite number of people in an organization, so creating a new column for each row owner doesn’t seem feasible.
I don’t know didn’t seem like a ridiculous request… 
Only Google Sheets will give you that… GS are faster and more comfortable to work with… also you can have unlimited rows and edits there 
Sounds like you should be using Roles as Row Owners. I have a post somewhere that explains how this can be applied. I’ll dig it out and link you to it.
Update: have a read of the below:
1 Like
Yeah maybe if that’s the only route 
. Could have sworn I saw a tip from glide somewhere mentioning the benefits to using glide tables around speed and syncing…
Hahaha… not if I’m the one who handles Google Sheets… then Glide tables stand no chance, LOL
Check my post with the English Dictionary… scroll all the way to the end… you will see how fast 2 million rows works!
1 Like
I appreciate the link. Sounds like this will get costly real fast using private users though, and with that a pretty low ceiling on the number of private users. Sheets may be the way to go. I’ll check back in a month after I migrate 
Scroll all the way down this post, lol
BTW… I just transferred the original App to a new folder… so it will work now… in the old folder, I have over 100 apps, so it reached the limit
And this one is with 2 million rows:
I have complete control over what and how it is downloaded… I can filter it before downloading.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.