What Data is actually downloaded?

[MGA]

I am aware that data is downloaded to the users device and know how to secure the data with Row Owners etc…

I am just curious to know what Data is actually downloaded, let’s use a Public Product Portal (using Glide Tables) as an example:

There are 3 tables:

-Product Table with 20 columns and 5 Lookups from the

-Helper Table

-Enquiry Table filled in by the User using a Contact Form on the Product Detail Page.

So what is downloaded:

-The complete database?

-Or only the complete Product Table?

-Or only fields from the Product Table used in an Collection e.g. the Table has 20 Columns and 5 Lookups but only 10 columns are used plus the 5 Lookups.

Also

-What if the Product Table contains 100 Product of which 50 are Offline, will these also be downloaded?

-What happens to the data on the Users device, will that be deleted automatically when he closes the app?

[ThinhDinh]

In short, any data that is not protected by row owners and roles setups is downloaded.

[Darren_Murphy]

Just to expand a little, the way I usually put it is as follows:

• If a table is referenced anywhere in the App, then all rows in that table that aren’t protected by row owners will be downloaded to a users device.

@MGA

What happens to the data on the Users device, will that be deleted automatically when he closes the app?

No, I don’t believe so. The data will be cached on the users device, and the next time they open the App it will sync with the Glide backend to pick up any changes.

[MGA]

Thanks @ThinhDinh and @Darren_Murphy all understood perfectly!

I am just wondering if there is a way to create a (read-only) subset of Glide Tables, which is called a VIEW in SQL SERVER.

I seem to remember reading about something like this e.g. shadow tables, query tables or similar, but can’t find it anymore.

[Darren_Murphy]

@MGA

I am just wondering if there is a way to create a (read-only) subset of Glide Tables, which is called a VIEW in SQL SERVER.

No, not really. At least not easily.
If you were using Google Sheets, then you would have some options using IMPORTRANGE, but there is nothing like that for Glide Tables.

[MGA]

@Darren_Murphy

Thanks again, seems that this makes it quite difficult to use Glide in a scenario where one has private and public data mixed.

Coming back to my example:

Imagine you have a Cost Price (Private) and a Sales Price (Public) in the same Product Table.

I am looking for a solution where I can create a complete (protected) back-office around a product e.g. Property For Sale which shows only a a small selection of Property data (1%) to the public but all other data (99%) is protected.

I am tending to create 2 apps, one private and one public with linked tables, but it seems that even this separation is not sufficient to protect some data e.g the Cost Price.

[Darren_Murphy]

I think in this scenario it may be worth considering having two separate tables - one for private (all) data, and a second for the public (subset) of the data.

You could take a similar approach to the one we use for setting up private/public User Profiles, and the tables could be in the same App, or as linked tables in two separate Apps.

If you’re not familiar with the approach, check out Bob’s tutorial:

Secure Your Data with Row Owners and Public Profiles

Hey fellow Gliders! Are you using Row Owners and Public Profiles to secure your user data? If not, you might accidentally expose private info. Let’s fix that. In this important tutorial, I demonstrate how and why to enable Row Owners, create a Public Profiles table, and onboard new users in order to safely create a community app that doesn’t reference the User Profile table. [Glide: Secure Your Data with Row Owners and Public Profiles] You can also reference this article in…

[MGA]

@Darren_Murphy

Thanks, will have a look right now.

I had actually already considered this possibility (master/detail) but had decided against it due to the doubling of Updates and User Input.

Could you please point me out where one can see the downloaded data in the developer console? There are so many sections and options, not sure where to look for.

Row Owners | Glide Docs (glideapps.com)

Anyone who can sign in to your app can see the data it downloads or stores in the data source, either in your app’s user interface or by inspecting network traffic with common tools such as a browser’s developer console.

[MGA]

@Darren_Murphy

I had already watched some of Bobs Videos about Security but must have missed this one!

I did some testing and it seems that this might (hopefully) be the solution I am aiming for*:

2 Tables instead of one:

The 1st one is Private:

The 2nd is Public:

Both related by Property ID.

So far so good, but what happens when Relations and Lookups are used in order to avoid data duplication, in this case the Property Reference:

Will this expose the Property Table? Or only the Lookup Value?

*Having one Private App and one Public App using linked Tables from the Private App.

[Jeff_Hager]

@MGA

but what happens when Relations and Lookups are used in order to avoid data duplication

Tables that are used by an app in ANY way (including relations) will require the data to be downloaded to the device. Just always assume that any tables used by an app will be downloaded to the device. Most computations happen directly on the device, so the data needs to be there for those computations to work. That includes relations which formulate on the device.

With the exception of data under row ownership that you don’t own, and data in user specific columns that is not your own, everything else is sent to the device if that table is used in ANY possible way.

[MGA]

@Jeff_Hager

Many thanks, if I understand correctly then simply switching from this

to this

and this

to this

should be sufficient to protect the Property Table inside a Private App since its protected by Row Owners whilst the Property Portal Table, having no Relations to the Property Table can be freely used in a Public App.

This solution will mean a bit more of development, user input and updates but looks like to be exactly what I am looking for.

[Jeff_Hager]

Yes, I believe your assessment is correct.

• All of the data in the Property table would be protected behind row owners, so only the owner of each row in that table can access the data in their respective owned rows.
• All data in the Property Portal table would be accessible to anyone as it’s not protected by row owners.
• The relation in the Property table can freely access all data in the Property Portal table.
• Even if you had a relation in the Property Portal table, it could only access owned rows in the Property table. (Relations cannot skirt around the security of row owners. (The data editor does not accurately reflect that though as it can show unowned data, but the app itself will fully respect row ownership.)