So if you have an app that ties two parties together like a market place, how do you keep the buyers from editing and changing content created by the sellers?
I know how to make data private … but how does the same data become read only? Does bubble do anything to prevent someone from hijacking the calls and replacing the visible fields with alternate data?
Anyone know how to handle this?
By the developer. They should add conditionals on Input elements to make them not enabled for the user type that shouldn’t have access…also by privacy rules if using autobinding…also need to consider conditionals on workflows too
Thanks @boston85719. Arent those conditions surface/UI level? If you poke behind the UI can you not just invoke a write?
So in my example the seller a job post. The buyer views the post. What keeps a reasonably tech savvy user from writing back changes to the job post? And for that matter the public parts of the sellers data?
Is your app open as an API?
No.
Im talking about injecting calls from the browser console when on the site.
Lets say the site has an upvote button on products. So a buyer can upvote a product. This would result in a workflow that gets the jobs upvote count and adds 1.
What is to keep me from just replicating that call to modify the upvote field on the job and changing it to … price … and changing the price? If a person that is not the owner of a job can change one field - what keeps them from being able to change any field?
There’s a reply somewhere on the forum from someone at Bubble that deals with this - I tried looking for it, but can’t find it.
Basically, my understanding is that Privacy Rules solve this.
If you have a data type, let’s say Jobs…with fields: x, y, z…etc, and you set privacy rules on the Jobs datatype, to only grant ‘access’ to the Job owner. With the exception of just one field: field x.
Now you perhaps have another data type, with privacy rules granting public access, called View Job, which has a field of the Job data type… in this scenario, they would be able to view job data, but can’t modify it, with the exception of Field X - which you had granted them permissions to access in the main Jobs data type.
I’ve never had the need to test this, but see if it works for you.
Interesting. so the second datatype captures a copy of the original data each time its viewed?
Not sure if “capture” is the right term… if you set the Jobs data type as a field on the View Jobs data type…any one that Privacy Rules allow access to View Jobs, will be able to “see” what is in Jobs, but not modify.
Like I said, if you have given access in the Jobs datatype for just one field to be accessed/edited… that will carry over to the View Jobs datatype, and they’ll be able to edit that ONE field
But do run a quick test for yourself. I’m only repeating this off memory of what I read from a Bubble employee on here, not personal experience
ok. Is this not a critical flaw though?
But since you mention “copy”… I should say that is how I personally choose to structure things on my end. I create a publicly accessible Datatype 2 that is in effect a copy of a private Datatype 1. But excludes the fields in Datatype 1 that I don’t want made public.
And then lockdown Datatype 1 completely with privacy rules.
Duplication of data, yada yada yada? Yes, I know. But this is what works for me, especially because it allows me to have separate pages/slugs for the 2 datatypes
I don’t know enough, to answer that. Again, maybe wait and see if someone else gives a more definite answer.
Like I said, I personally choose to duplicate the data - and have the ‘public facing’ datatype out there, with a reference to it’s ‘private’ version
I re-read your protection mechanism and im sorry but I dont get it. How does it work?
I have a datatype X, which has 10 fields. Three of which I want to keep private. Every time a datatype X is created, I run an API workflow which creates a datatype Y. It then copies/duplicates the entries from Datatype X, onto Datatype Y. But only 7 fields. The 3 private fields are left out.
Datatype X stays private forever, only accessible to the thing’s owner, locked down with Privacy Rules. While datatype Y is public. When changes are made to X, another workflow updates Y too. When info is added by the public to Y, that is relevant to X, that gets linked as well. (There is a two-way link between X and Y)
To whatever end someone could ‘hack Y’, it would never interfere with X.
May not work for what you need, but thats what works for me.
In your example, assuming you want them to be able to edit just one field on X, grant them access to that single field on X via privacy rules.
For the other stuff you want them to see, but want to be sure they can never touch - duplicate them and store them on Y…then set lax privacy rules on Y.
Thats how I make do …
@obvolut and @PineappleJoe privacy rules do not affect a users ability to modify the data except for the use of the autobind
View all fields, is for the purposes of making the data visible…find in searches is for making it available in a search (use as a constraint perhaps - or just exclude from search results) and the view attached files is about private files (images/files)…none of those are associated with running a workflow to make changes to your database as far as I am aware.
The only way to make sure users who don’t have ‘permissions’ to modify data is to make sure your workflows used to modify the data have conditionals on them as such.
In regards to the autobind privacy rule, that is only associated with the use of the autobind feature of an input element…the reason it is there is because there would otherwise be no way to restrict the access because there are no workflows associated to set conditionals on.
I would say you contact Bubble Support directly to get clarification on this topic and it would be beneficial to report their response on this thread so other users would have a clear and accurate answer on the subject.
Also, have you tested this? Have you been able to inject a call into the browser to affect your sites database?
@obvolut Thanks. I understand though I think the only way is if the link between Y to X had definitive proof that the back end call was initiated by the owner of the particular record … and im not sure how you can know that. Not because I’ve tried to know but because I just dont know if bubble lets you definitively know that.
@boston85719 Yeah im going to contact bubble. I tried to reference their people (Jess) directly but no engagement. I havent tried to break it yet… it would take some poking around to get the right call in place.
Edit: I emailed them. I suspect the protection they have is in the link itself. If they have a way of knowing that the call is indeed coming from them and them only then its … secure. Im going to reach out to a security pal to see how much of a concern this is as well.
I’m still confused. Are you talking about accessing the Backend Workflows (AKA API workflows)? Or just through your browser calling to the app database to make a change even if the app doesn’t have backend workflows enabled, or the API enabled?
This topic was automatically closed after 70 days. New replies are no longer allowed.
