I would like to pick up the topic again.
As mentioned in the Security Center documentation of Glide: The visibility conditions are just so the end-user does not see specific elements. Like not “see” an edit button → not stop the underlying network requests which can be manipulated by any one with coding/network understanding.
The editing element is only generated by Glide when conditions are matched. As far as I aware, adding things in the source code does not grant the ability to mimic that button.
A potential bad actor does not need to look or change the source-code, they look at the network requests and can manipulate a request to tell the server to store potentially any element or data.
Most importantly, it will never allow editing a row in a table that has row owners, where the row is not owned by the logged-in user.
Although, this is true for a column with a ‘Row Owner’, the use case which the topic owner describes is different: All can see, only specific users can edit
Does not allow the use of a Row Owner, as this would prevent every user to see all data.
Glide has a bunch of security checks on the backend.
When inspecting the network traffic of an edit request (when the user clicks save/ready), the browser directly sends data to the Google Firestore API, which is NOT the Glide server, it’s directly connecting to the database.
It is possible to set up security rules within a Google Firestore database, the question would just be if these are automatically set when we create a “condition” in the Glide interface for the Edit/Add buttons?
Then there is still the “Visibility is not a security feature” dialog warning which pops up as soon as you try to add a condition for edit/add-form the Gilde interface
There are still lots of unknowns and I would appreciate a clear answer from the Glide team as this is security-relevant!