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.
You can also reference this article in the Glide Docs:
For more info on securing your data via Roles, check out my previous post here:
As always the video is beautifully produced and particularly informative.
Iāve been going back and forth with this idea of having two user tables, one private and the other public. I have two issues with this, itās probably just me:
It feels wrong to have two tables to achieve this security feature. By design in the way you do it, data is duplicated. My issue with duplication has nothing to do with the financial cost to the Glide developer, but rather why add more rows when there could be less.
Itās too complicated for the billion developers to do what you showed, though the security measures you showed are very important.
Would the security issue be solved if columns could be made private? (This is originally what I thought the Protected Column feature was for though was mistaken.) If made āprivateā, data in the cell of that column could only be seen by its associated row (like row ownership, but at the cell level and determined along a column).
I wonder how itās done in the coding world. Two users tables as well?
Yaā¦itās not ideal to duplicate data, but currently itās best practice and is the recommendation from Glide. Iād also like to see ācolumn ownersā (eg. āonly Admins have access to phone numbersā), but I canāt visualize how Glide would pull that off.
ya reckon?
If this is considered too complex for the average user, then I think weāre setting our bar way too low.
Iād suggest that anyone that finds this too difficult probably belongs in that larger group of 6 or 7 billion non-developers
I think thatās more about the Glide architecture than it is about code vs no code.
In a typical client/server model, the client would be requesting data on demand via an authenticated API, and often there would be some sort of role-based permission model working in the back end that determines which data the client is permitted to access. Glide are currently beta testing a server side computational model. Once that becomes a thing, then these types of workarounds might no longer be necessary. For example, with server side computations and lazy loading of data - then computed columns as Row Owners become possible (in theory, at least).
I donāt disagree with that. My point was that there is nothing in Bobās video that should be beyond the reach of anyone. There are no āmagic tricksā or really advanced techniques, just standard things like tab visibility and set column values through single relations.
Please note that Iām not trying to detract from the tutorial in any way. Itās superb, as always, and will be a great reference. We can never have too many of these sorts of tutorials.
But from a userās view, I think choosing which columns of a profile should be private feels more logical and easy than having two related tables with overlapping info and automation.
Again, I donāt disagree. And I wholeheartedly agree with @nathanaelbās earlier comment about data duplication. It violates a basic rule of database normalisation. But, we have to work within the current constraints, and what Bob has demonstrated is the (current) best and simplest approach.
I have no background in programming so my thoughts are mostly guided by my naive intuition. Database normalization makes sense to me for instance.
The way I see Glide is that we are programming. Visually. Many aspects of traditional programming, however, do remain: for whom, the user experience, road maps, algorithmics, database design, design patterns, etc. The main part that Glide saves me from doing, I feel, is developing proficiency in the grammatical syntax of programming languages. But the algorithmic effort remains. At least thatās how I think I see it, as of now.
So I do expect that our visual programming in Glide be in line with usual practices in programming. If data duplication is a bad practice in the coding world, then I donāt want to see it in my work in Glide.
That being said, āwithin the current constraintsā is key. As we know, the Glide team does an outstanding job at breaking down these constraints.
Love the conversation going on here. I think we all agree with everything everyone is saying:
thereās a need to data security and a responsibility to the developer to create the app with data security in mind
Glide offers data security via Row Owners
current best practice is to have a separate public profiles table IF you want to have a community portion of your app WITHOUT exposing user data (like emails, etc).
in the future, Glide can make this easier for the ā1-billion developersā by allowing for server-side computation, but for now we need to develop within the walls that weāre given.
Maybe someone from the glide team wants to chime in here?
Hey fellow Gliders!
