🆕 Security Center

[V88]

@david @Mark

I have a query about a specific scenario that I keep coming up against and which I think still requires me to utilise 2x Pro apps for security reasons.

I’ll try to explain:

Imagine a customer who has a restaurant business. They have public information that anyone can see and also member sign in for customers who are part of their loyalty scheme. So my app is Public Pro but supports user profiles. That’s all good.

Now imagine that the public section of the app displays latest offers and new menu items. Somebody needs to “administer” those details i.e. add new items. Typically this will be one or more members of staff. I had thought this could be handled by a simple Admin flag in the user profiles table. The flag would use visibility to enable adding and editing of such items.

However, based on my understanding, this is easily bypassed. Using the browser inspect element capability a malicious person could alter the Admin flag amd therefore gain visibility and access to the lates offers etc. Clearly an issue.

So it seems that I have to revert to another app, just for Admin users. Am I getting this straight guys? If so then I’m back into double costs again

[david]

Just make sure to use multiple row owners for the staff who are editing in this case, and display the readable deals in a mirrored sheet.

[V88]

Hi @david - thanks for the reply - two queries:

Regarding the mirrored sheet technique, am I right in assuming that this all happens in Google ie. we have a sheet with the “source” rows in protected by row owners and then use a Google formula to “duplicate” these into another sheet which the public (and other non-admin) users read?

Regarding the multiple row owners, I have yet to find a way of implementing this technique “dynamically” so that the customer can allocate and de-allocate their own admin users as they deem fit. Can you suggest a way forward?

Cheers.

[Jeff_Hager]

That would be my take on mirrored sheets.

As for multiple row owners, my take is that you would have an array of columns set up in the sheet to use for row owners. One column would be set up for the customer and any other columns could be edited by the customer to assign admins. So they would edit individual columns, but you would use the combined array for setting row owners.

[V88]

Thanks @Jeff_Hager. The issue with the multiple row owners, as I see it, is how do I allow for a customer who might have just one or maybe 20 admins? They will only have the app UI available to edit their admin allocations. No access to the sheet. So I am therefore probably stuck with adding in, say, 50 columns “just in case” and then trying to build the UI to populate them (or not) sequentially?

[Deena]

Forgive me if I am wrong, and definitely need someone from glide to confirm this, but I believe that anyone with a role of admin can be added to the array. So you would not have to do any manual work there. Or build a bunch of columns. You would just have to assign them the role of admin.

[ThinhDinh]

Deena is right. The setup should be like this if I understand everything right:

• In the User Profiles, have a Roles column that sets the “Admin” text value to the column that you will use as “Roles”. Other values can be user etc.

• In the other sheets, have a corresponding Visible Rows 1, Visible Rows 2 etc. On rows you want to show to Admin only, give it only an admin value. If you need the user to see it as well, add “User” to Visible Rows 2 and so on.

[V88]

@Deena and @ThinhDinh thanks for your input. I have been thinking more about this and I still don’t fully understand your suggestion if I’m honest.

My current belief is that the ONLY thing we can be sure of is that Glide will return only rows where the current logged-in user is a row owner. This is not an “app visibility” trick because the non-matching rows are not “hidden” - they are not even returned to the app.

In the case of visibility, however, data is returned, but the app uses logic to hide that data. It’s actually there, in the app, but hidden, so we can change our logic to show it based on certain conditions if we wish.

The second scenario is not secure since it is possible, using the browser inspect element function for example, to view this data and even to CHANGE it app-side. This means that one could change the value of, say, the Admin flag in a returned row from the User Profile sheet. Then the various visibility rules that depend on the flag would trigger.

So returning to my scenario, there is a sheet that holds, say, a row for each item that the restaurant sells with a name, description, photo and price. Public users and customers (who will have user profiles) should be able to see this entire sheet freely BUT not edit it. One or more members of staff (who also have user profiles) should be able to edit this entire sheet. It SHOULD be possible to do this in a single app.

@David has proposed using sheet mirroring and I get that bit. The “master” sheet can be made available for staff to edit and we can use a Google sheet formula (not yet tried this) to duplicate the entire sheet into a “slave” copy which everybody can read. So far so good.

However the only way to restrict access to the “master”, without relying on visibility, is to use row owners. I know that we can assign a single row owner to a row or multiple row owners by using an array column. However I do not know in advance how many row owners are required and who they are. These are essentially the staff and will be configured by the restaurant from the app UI. We have to do it this way because Glide does not yet support built-in “roles”.

So the question remains, how do I allow the end user, via the same app, to manage the staff users who have the ability to update the “master” sheet in a secure manner? If I do this based on any flag in the user profile row then I imagine it can be easily circumvented?

Or am I totally missing the point somewhere!

Thanks in advance for any guidance.

[ThinhDinh]

@V88

However I do not know in advance how many row owners are required and who they are. These are essentially the staff and will be configured by the restaurant from the app UI. We have to do it this way because Glide does not yet support built-in “roles”.

They do now, with Sheet columns, if that’s what you want to refer to.

Glide Docs

[V88]

Wow. That’s interesting and potentially VERY powerful indeed. However I still foresee two issues:

1. There is this restriction:
   

   

2. What stops a user changing their role in the browser “inspect element”

@Mark can you provide any assistance / guidance here please? My potential customer is asking for clarification and I’m struggling without adopting the “dual app” approach.

[ThinhDinh]

Can you specify the changing role in browser “inspect element” part? I thought those pieces of info are now all secured via base64 coding.

[V88]

Yes I’ll try.

I am no security expert, however if you run a Glide app in the browser then you can right-click inspect element to view the HTML elements. Everything that has been sent to the app will be available for you to see in here and also to change (of course only in the browser not at source). I am assuming that your user profile information is also in here somewhere (the app would need it for visible checks etc). Therefore I assume that you can also see the contents of the role column for your profile. And therefore change it? This is why I am seeking some clarity.

I have users asking questions about data security, for obvious reasons, and whilst I feel comfortable with the “dual app” approach I do not know enough about Glide to feel just as comfortable with the “single app” approach.

[ThinhDinh]

My understanding is:

• Glide loads the data you want them to load to the end user via a JSON.
• You can control that using the old row owner approach, or this new roles approach.
• The JSON file is now secured via base64 coding, and it takes into account your roles settings so only sheets without those will now load to the JSON. Me and Deena did test this to confirm the JSON won’t expose data anymore and it doesn’t.
• I’m not entirely sure about changing a “flag” to change the role column, but that should not be possible because it’s only a “local” settings on that specific session and that should not initiate a ping back to the Sheet to show new data.

[V88]

Hey @ThinhDinh that’s really interesting and good to know that @Deena and you have both been looking at this. It would be great to get confirmation from @david or @Mark or any other Glide Team member about how this works. Do you know if that currently exists on any other post that I may have missed? Thanks.

[ThinhDinh]

I don’t think I have seen the “Roles” mentioned anywhere else but I think there will be more Glide communication regarding role-based security and protected columns in the coming days.

[V88]

Aha. That also sounds “super interesting”. I imagine that’s what they’ve been working on. I’m sure it’s a very significant undertaking. May I ask where you got that Updates screenshot from?

As an aside, I wonder if protected columns answers my various ramblings above?

[ThinhDinh]

https://docs.glideapps.com/all/guides/security-center

It’s in the link David posted haha. Me and @Deena only tried role-based security, seems like protected columns are not out yet.

[V88]

Oh yes. It’s changed since I looked at it last time. Also I didn’t see an Announcement for roles, so maybe that’s yet to come.

Thanks so much for the “chat”. It’s been really useful. Let’s see if @david or @Mark can chime in here to just nail my customer response, even if it’s just to say “yes it’s coming soon”.

Cheers @ThinhDinh

[ThinhDinh]

Have a nice week yourself man! Hope the chat helps!

[Mark]

We hope to ship protected columns within a week.