🔒 Why Privacy Rules in Bubble.io Matter More Than You Think – ratio.dev

Hi, I'm Dennis Lewis from Ratio.dev and in this video I want to share with you some privacy rules, best practices for your bubble application. So before we get started, let's just talk a little bit about why privacy rules are so important. And there's basically two major reasons why you really need to be implementing correctly your privacy rules in your bubble application. Obviously, the first one is security, because they help you maintain privacy over the data that can be seen not just visibly in your bubble application, but anybody who wants to just look into the developer tools console of Google Chrome and inspect the data that's being sent not from the client and to the end, from the server to the client. And we'll talk a little bit more about this in the future. And the second thing that's really important is for. For performance, often your tables have a whole lot of fields in them that are used for backend functions. They're not relevant to anything that really pertains to the user's experience. However, bubble, whenever you pull data from the server to the client, it's pulling all of the fields that the user has access to. So if you don't set up your privacy rules correctly, you may be flooding your user's browser with a bunch of data that is not only not important, but it's just slowing things down. So oftentimes, using the privacy rules correctly can really improve the user experience for your bubble application. So both security and performance are the two big reasons why privacy rules are really important. Let's talk a little bit about the reality of client side searches inside bubble. What is, not what you get. Okay? And in fact, let me just quote to you exactly what bubble says. As a developer, you need to be aware that as long as the data has been downloaded to the user's device, even if it's not displayed anywhere in your app, the user of that device can access it by looking at the data traffic being sent to it from the bubble server. Okay, now what that means is that if you query a table in your database from the client, all the data that is sent is visible inside the user's browser. And it's not hard. In fact, if we just were to go visualize a simple bubble application, or any bubble application, let's just do a preview of a page here. Meanwhile, I'll just let this page load. We can see how easy it is to get in and look at the data that's being pulled from bubble to this user's browser. So in fact, here I can just go to the and do view Go to the developer section and go to the developer tools in Google Chrome and it will open up here. And I can go to Network and I can just start looking at any objects that have been brought. I'm going to refresh this page.

And when I do this, I can scroll down here and see.

If I make this maybe a little bigger, it will probably be easier to visualize. I can come down here and actually see everything that's being loaded into the page and I can look at the data. So if I go here, this is bringing in data from my application and I can just come into the payload section and look and see. In this case, it's not. There's nothing really too interesting in there. You can come in here and look and you can see in 30 seconds, you can find the data that's being pulled from the Bubble database and visualize it in the browser. You don't have to be a hacker, you don't have to be a developer. You don't have to be anybody with special training or unique skills. It's just there. That means that you really need to think about how to do this. And the truth is that Bubble will always pull more data than is absolutely necessary because it's trying to anticipate what the user may need in the near future so that it doesn't have to query the database and make them wait. It's pulling in related tables and it's pulling in data that you probably don't realize. So that's really important. So there are two types of data that you need to think about. Public data, which is your product list or your blog post, and private data, which might be your sales history or your shopping cart data or the profile information about your users. And obviously, public data will need to be less scrutinized than private data. You need to be even more careful with private data. But you really. And oftentimes you need to have privacy rules for all of it. Okay, so how do privacy rules work? First of all, they're going to be in the privacy tab of the data section of your bubble builder. So you can come in here and you will see all of your data types here. The ones that say publicly visible, they don't have any privacy rules set up. And the other ones have privacy rules applied. Okay. And each privacy rule has two parts to it, the rule and the consequences of the rule. So here we have the rule, which is up here at the top. We've given it a name. And this is what determines this rule, and this is what determines what happens to the rule the consequences. So we're going to talk about the best practices for both the rules and the consequences. The rule section should normally reflect a user role. Is the current user logged in? Is the current user an admin, or is it a marketplace user? Whatever the functionality of your application is, that's what you would want to use normally as the rule of your privacy rules. And then the consequences are can they view all the fields? If you're. Let me just go maybe here to articles.

So if you're an admin, so in this case current users, current Personas admin is admin or current user type is super admin, then you can view all fields. Okay, you can view attached files and you can find in searches if you're the owner or the author, more or less the same. Otherwise everyone else can only view a certain number of fields that make sense that they might want to be able to see in the user interface or need for some function that we're using in the user interface. You can also control whether they can use auto binding, which is a powerful way of setting up your screens so that they automatically update the database. You can determine whether it can be created via API or modified or deleted via API. And so you have a real granular control over each rule. The consequences that it can have Use view all fields sparingly. That is one of the best practices. This is okay for admins, but don't use it very often. View all fields. Always keep your internal fields unavailable. This will speed things up. So the fields that aren't really relevant to the user experience, don't send them. They're not going to be of importance. So just that's data will not be pulled and it won't be sent. So it will make your application faster. Don't activate auto binding unless you expressly need to use this. No reason to do don't activate find in searches if you can navigate through your data database to the correct data. So if current users current orders, first items, invoice number if I can go through the tree and get to that data, then I don't need to do a search. So don't give them the ability to do a search. Okay, so some things you need to keep in mind with privacy rules, you don't prohibit access, you grant it. Okay, so that means that you're allowing certain user roles to do certain things. So if you don't allow it, it's not going to happen. Okay, so that's a good way to think about it. A good way also to think about Privacy rules is that the most generous rule that one gives you the most access is the one that will override any other rules that the user has access to. So a user could be an admin and he could be the owner of a blog post if admin has more capabilities and the consequences of the rule section, those are the ones that are going to be used. Okay? So it's always the most generous rule that the user can passes is the one that is going to be utilized. And always remember that the last rule, the bottom rule, everyone else is the most critical one. So that basically means if the user's not logged in, if they're not an admin, if they're not the owner, if they're not anything special, what can they see? And oftentimes they don't need to see anything. Okay. Or very little. Make sure you make that last rule as tight as you can when you're debugging them. Can be a little bit complicated because you're going to wonder why things don't work and it doesn't come out and say, privacy rule violated or this isn't working because of a privacy rule. It's just not going to have the data. And so it's not going to work. And so you're going to scratch your head. You're going to go, why isn't this working? Or why can't I get to the right to. Why isn't it showing me what it should be showing me? It's not giving me any errors, but it's just you don't have access to the data. You do need to. When you're setting up your privacy rules, you're going to need to test your application well, to make sure that you haven't tightened anything down so tight that it doesn't actually allow you to present to the user the functionality that they need. And the last part of this video I want to talk about are privacy rules and workflows. Because privacy rules are for data access. Okay. And if you read the bubble documentation, the question is, do privacy rules affect your app's work workflows? And they've been really clever in their response, and I'll quote, this is. The answer is yes and no. Okay. So client side workflows are going to be run as the user. Okay. So if the user can't see data and it's a client side workflow, then it's not going to have the data and it's going to do whatever the workflow set does without the date. So it's going to see empty. And if it's empty, that may mean your conditionals don't work, or it may mean that you can't see the information. However, you can create information because privacy rules control what you can see. So even if you don't have access to a table via privacy rules, you could still, in a workflow, create a row in that table. That'll work. That's fine. You can update a row in the database. You just won't be able to see the results. So you won't be able to actually show those in your application. So that's why it's a yes or no. Now, server side workflows, backend workflows. You have an extra thing that you can actually click off on when you set up a backend workflow and say ignore privacy rules or allow privacy rules to be ignored. And sometimes that is something that you may need to do in a workflow because it's happening on the server. So there's no risk that information is going to be shown to anybody in their browser, because it never goes to their browser, because that is a backend workflow. To protect workflows from performing tasks you don't want it to do, you'll need to use conditional expressions in the workflow so that it only runs in X condition. Okay? Because like I said, you can do actions on tables even if you can't see them. So hopefully this quick video has helped you to better understand privacy rules in your Bubble application. If you have questions, leave them in the comments below or send us a contact request@rachelor.dev and if you need help debugging your privacy rules or setting up your privacy rules and you're not quite confident enough to you're going to get it right, just reach out and we'll be glad to help you. Hope you've enjoyed this video and I'll see you on the next one.