I have some questions regarding data and security, that I will post one by one and it will be wonderful if anyone can give some answers regarding those questions, one by one.
@Sean_Martin … these are the questions that maybe the team can have a look at.
Can users that are not signed in see the data for the features that require a user to be signed in ?
Recording
Can users that don’t match a certain criteria access pages that are not available to them ?
Let me make it clear first about “being able to view” and “being able to download the data”.
Data that is not protected by row owners or roles setup will always be downloaded to the user’s device, when they use your app. Filtering data from the user’s view, without protecting them using row owners/roles is not a secured method.
Hence for this question, if the user can not see the tab but you don’t protect relevant data (from your tables) by row owners/roles, then the data is still downloaded to the device.
No, I don’t think so. I don’t believe the add button is generated at all when the signed-in user does not have access to it, so it’s not something a person can toggle on or off using CSS.
The two ways people can add a row to a specific table is being able to add it based on your configuration from the app, or create a HTTP call to write data to your Glide Table, but that requires a lot more things security wise, let’s say the secret key is one of them.
No, that profile screen is “filtered” to the signed-in user’s row. You can’t edit another person’s data through that screen.
Please beware that unlike an edit screen, entry components straight on the details screen like that will write directly to your db, and there’s no “Cancel” option to revert all the changes.
And personally I never allow people to change their email. It is connected to the signed-in user’s profile, and might force the user to log out of that session to be able to use the app again. Not a good experience.
@ThinhDinh you are a rockstar … thanks for your help, regarding my first question, so, all data is downloaded into the app if not restricted by row owners or roles, that means that the data that is protected by those 2 options is downloaded on request , or how ?
Regarding my 4th question and 1st questions … if data that is not protected with roles or with row owners is downloaded to the app, and is not secured … that means it can be accessed by someone or just is not as secured as those 2 options .
Row owners is very limiting in terms of viewing and roles is very limited in terms of plans … so those 2 would not work for what I want to achieve … but I want to understand the risk that data can have because also, it’s not very sensitive data but still. So in the case that I protect that data to be viewed only by an user, can someone without an username be able to see it, or another user that doesn’t have an option checked into his profile.
I think most, if not all data is downloaded when the app is opened. I think things like computed columns are maybe computed as needed by the app, but otherwise the data is already on the user’s device.
It’s JSON. In a lot of cases, it takes me less that a minute to open an app, decode it, and snoop the data. Usually it’s the tables that are not under row ownership. I’ve had a harder time with some apps, but not all (just my lack of knowing where to look). So, yes it’s visible by anyone if they know how to find it.
I stress data security a lot by using the security features that glide has provided. Trying to skirt around it will not lead to a secure solution.
I would use them, but with the limitation that is for private users which also means users with roles it’s impossible to achieve what I want … maybe I will remove this feature as I don’t want to not be secured
I’ve read all of your posts. I think you understand very well how glide works and what your limitations are, but I don’t believe there is a way to get exactly what you want.
I’ve figured it out with those custom actions … I can achieve that and also keep everything I need restricted … if someone wants to be public it would be the choice of the user not the app… so it’s good.