Protecting Data
Until you set Privacy Rules, all data created by your users or yourself can be read by anyone. Anyone with some programming skills can view all your app's data, even if there isn't a page in your app that explicitly shows the data to users. That's where privacy rules are important, they guarantee data is only shown to people who meet some criteria. Privacy rules are enforced on the server, which makes them secure.
When you create a new app, all data is open to the public. This is appropriate for things such as comments on a blog, where you want to share it with the world. However, many apps involve users submitting information that you don't want to share with the world, such as their names and emails, or comments meant only for people they already know. Privacy rules are the tool Bubble gives you to protect that information and make sure it is safe. If you haven't explicitly created privacy rules for a given thing, then the data is not secure.
Any data type (the types you define and the User type) can have privacy rules. A privacy rule is composed of two things:
The condition. This defines if a rule applies to a specific situation or not.
The permissions. These are the type of things a situation that meets a condition enables a user to see.
A privacy rule also has a name, which is only used for editing purposes.
The condition is a dynamic expression that should evaluate to yes or no. The Issue Checker will flag expressions that aren't evaluating to yes/no as an issue and should be fixed. See an example below that makes sure that only the sender and the receiver of a 'message' can see its content.
The first rule lets the sender and the receiver of the message see all the fields, see attached files if there are any, and will ensure that search results include messages that fit the rule. The second rule, the standard one, hides all fields and files from other users, and makes sure messages cannot be found in searches. You can add some constraints in your searches to avoid some results showing up, but using conditions makes it more secure and readable.
It’s also common to differentiate between user or subscription roles in your application; for example, you might have “Admin,” “Supervisor,” or “Member” users, or “Free” or “Premium” subscribers. In this case, you might add a “Role” field to your User data type, so that you can then define privacy rules based on what you would like each tier of user to access. For the former example, you might have a “Invoice” data type with a privacy rule that when the current user’s role is admin, they can modify an invoice. For the latter, you might have an “Content” data type, with a privacy rule that when the type of content is premium only, and the current user’s role is premium, they can view all fields of that data type.
These are the permissions that a rule (when met) grants. When multiple rules apply, the user has access to an object if any one rule grants access to it.
View all fields. If you uncheck that box, you will be able to pick the fields that users in that rule can see. If you check the box, all fields will be visible. Unchecking all the field boxes will ensure that users in that rule cannot see any field.
View attached files. If this box is unchecked, users won't be able to see uploaded files that are attached to a thing of this type. You attach files to things when the files are being uploaded, at the file upload element level.
Find this in searches. Uncheck this box if you want to prevent users that are in this rule to see search results for this type.
Allow auto binding. Check this box to allow users in this rule to modify things through auto-binding. You'll have to pick the different fields that can be modified by users in the current rule.
If you have multiple privacy rules, there's a chance that a user could fulfill multiple of them. So what happens in that case?
The privacy rules are essentially additive. If a user fulfills multiple privacy rules for a given type, they will have the highest level of permission in each parameter out of all the rules they fulfill.
If a user fulfills no custom privacy rule, they will, of course, default to the "Everyone else" rule.
Note: Privacy rules do not update automatically on the page if the privacy rules impacting a user change while the user is on that page. For example, if a user has a page open where they can see a Thing, then they click a button on that page that changes which privacy rules apply to them such that they can no longer see that Thing, this new privacy rule outcome will not reflect on the page until the page is refreshed.
Using privacy rules can make debugging harder, as some data may not be visible in your workflows. The debugger has a special mention for things that have been altered by privacy rules.
Privacy rules do not apply to modifying data through workflows. If you only want certain users to modify data, you can add a condition on the workflow's events and actions. These conditions are checked on the server, so this is just as secure as setting up privacy rules for modifying data through auto-binding.
Note: Workflow descriptions are sent to the client-side page regardless of privacy rules. Consider the following scenario:
A page has a workflow that creates a private Thing and sets a private Field to a visible value (like '123456'). Because we send the workflow description to the client-side page, this data should not be treated as safe, and should not be used when privacy is important, like generating a static password.
For better security, consider scheduling a Backend workflow, as this code will never be sent to the client.
