How to control data access?

[Wayne_S]

Hey,

So I need parts of my app to be viewable publicly and other parts only viewable by the signed in user. This will differ based on the signed in user role type.

Seems to be quite a few ways to achieve this, but what is the most secure way to do it?

My app is currently set to public with an optional sign in.

Cheers!

[Jeff_Hager]

Using Row Owners applied to columns that contain an email or a role would be the most secure method. (When utilizing Roles with Row Owners, then you do have to configure a role column in your user profile configuration.) Rows with Row Owners applied will not be downloaded to the end user’s device if they don’t own the data.

[Wayne_S]

My understanding is that the app has to be set to private to use roles, so would this still apply to my use case, where parts of the app are public?

[Jeff_Hager]

You can use Roles on a Public app.

The only difference with Roles, is that any users that have a role applied will be considered a Private user. That doesn’t mean that the app has to be a Private app.

Roles are simply a way to easily apply Row Owners to a group of users without needing to specify each individual email address.

[Wayne_S]

Thanks Jeff - so this does not apply or am I missing something? Glide Docs • Roles (glideapps.com)

Edit - I think I’ve got it! I’d missed option to make the column “Make row owner”! Makes more sense now!

[Jeff_Hager]

I think that document is a little deceptive, and needs updating. The need for a “Private Plan” was the case with an old pricing structure. With the new Teams pricing structure, there really isn’t such a thing Private or Public Plans. Now it’s all one Team “Plan” that can have a variety of public or private apps. Now you have to pay attention if you have public or private USERS and what your user limits are for your plan.

Users are considered private users only if the entire app is set to Private, or a user is assigned a Role. You can however, have a mix of private and public users in the same app if only certain users have been assigned a role.

I’ll notify the Education team to update the documentation. It’s been a work in progress for them.

[Wayne_S]

Ok so if the app is public, and someone signs in but dosent have a role assigned, they don’t count towards your private user count? And I can still restriction data visibility based on the email address using filters?

Sounds like I have alot more flexibility than I originally thought

[Jeff_Hager]

Correct.

• A user WITH a role should be counted as a Private user.
• A user WITHOUT a role should be counted as a Public user if they sign in.
• A user that is not signed in is considered a Visitor.

Row Owners will apply according. In any case, if a user does not have authority to a row under row ownership, then they will have have any kind of access to that row whatsoever.

I think from the sounds of it you should be fine. Just apply row owners where necessary and it should all work out.

[Wayne_S]

Thanks that’s great, I can do a bit more than thought without needing to worry so much!

I just need to figure out how best the use the optional sign in for my use case!

Cheers Jeff, very helpful as always

[Wayne_S]

@Jeff_Hager - one more question springs to mind, can I still set a row owner column without setting a role owner and therefore not using my private user quota?

[Jeff_Hager]

Yes, you can. If you don’t use the Role feature, then you will only be able to set columns that contain email addresses as a row owner columns.

Keep in mind that you can actually have multiple columns set as row owner columns if you need more than one person to be a row owner.

[Wayne_S]

Ok - I’m still not 100% sure I’m setting this up correctly to ensure that data is secure.

I want an admin (who is my client) to be able to add users so I’ve set up the user table like this:

With the visibility conditions like this:

Leaving the role blank on the in-built user side menu tab, like this:

Bear in mind that the app is set to public, with sign in optional, so the idea is only my client will be able to see the user tab to add and delete users.

This works, but how secure is it, given I’m adding an extra screen for users and using filters.

[Jeff_Hager]

Row Owners applies to the data in the table. You are showing one row, with your email in both columns. That means that when you are signed in with that email, you will have access to that row of data. If anybody else signs in with a different email, they will not have access to that row, because the email they used to sign in does not match the email in either of those two columns. Their device will only download a row if their email is contained within one of those two email columns.

Leaving the Role setting blank in the user profile configuration is fine. Like you said, it will prevent users from being designated as Private users.

As for tab visibility…and any time you specifically use the user profile in visibility conditions or filters…it will always look at the user’s own specific row for that signed in user (in case you haven’t noticed, whenever a new user signs in for the first time, a user profile row is automatically generated for them).

So, when setting tab visibility, it is using the signed in user’s row, and you can set conditions based on any column in that user’s row. I think you went a little overkill on the conditions. You should be able to simply check if your Role column has Admin in it. That should be it. Any user that has Admin in the Role column (in their own user profile row) will see the Users tab. Only the admin user’s row should have ‘Admin’ populated in the Role column. For regular users, it should be left blank. You are just checking if the tab should be visible based on that signed in user’s own user profile row.

This setup should be secure due to the use of Row Owners. The email column will contain different emails for each individual user, so each individual user will have access to their own row. Assuming the Added By column will always contain the admin’s email, then the admin will have access to all user rows. The psuedo Role column will only be used to control visibility of the User’s tab. If the Admin is the only user that has that designated psuedo Role, they they will be the only one to see that tab.

I hope that’s clear.

[Wayne_S]

It is clear indeed and thank you, this is what I expected, but the warning the system gives has made me question how secure it is, I wouldn’t want someone to hit F12 and be able to see the data!

Thanks again.

[Jeff_Hager]

No problem.

Yep, Row Owners is the critical part here regarding data security. Just dial back your visibility conditions on the tab to just check the Role column value. Your setup looks good otherwise.