Section 4 (Lesson 4/10): In today’s digital age, user privacy is a top priority. In this lesson, you’ll learn the importance of privacy rules, how they operate, and why they should be a central part of your development process from the start.
In summary, we’ll be covering:
Privacy rules: Understand why privacy rules are your first line of defense in safeguarding user data.
Server-side security: Learn the difference between server-side and client-side access to data and how it relates to security.
Resources folder: ➡ https://e6387a14ba6d0bf3e823090f8d959...
Bubble editor: ➡ https://bubble.io/page?type=page&name...
Transcript
Privacy rules are the most important safeguard you have to protect your user's data, and I'd strongly encourage you that you get to know them well and make a habit of implementing them from the moment you create as well as edit your data type. Privacy rules act on the server side, making it impossible for data to be stolen, tampered with, or accidentally leaked, since this information never leaves the server. And Bubble has strong security features in place, but we don't enforce them; it's up to you as a developer of the app to use them in the right way to make sure that your user's private data stays private. Anyway, let's do some privacy rule testing to learn how it works!
So we've talked about this checkbox ("Make this data type private by default") a numerous amount of times now. Now we're going to actually dive in to see how this works. So on the User data type, whenever you create an app, you will have a rule applied by default. And if I click on this "Privacy rules applied" link, it takes me to the Privacy tab and now we're looking at the User rules, and this is what Bubble sets up by default. The name is "User's own data," okay, so from that, we can deduct that it looks like we want to protect our own data as a User. And the "When" expression reads "This User is Current User." We're going to be writing some other similar expressions for other data types, so don't worry if you feel a bit confused about what this means. I just want you to remember that the Current User is the person holding the mouse, so that's often the context of these rules. So we are providing access to data from the server to the User holding the mouse, and we're going to get into testing very soon. Th3 "When" expression always needs to equal a true or a false.
Then beneath this expression, it says "Users who match this rule can..." and if this User is Current User, meaning that a User is looking at their own data, then they can view all fields, find in searches (such as a repeating group), view attached files (which we'll be doing with CV Uploads in PDF form), and then allow auto-binding, and auto-binding we're not going to cover in the course, but it basically allows you to save data from an input without having to use a save workflow (it just updates from the input automatically). Then beneath that, as part of this specific rule, we have what everyone else can do?, and I basically unchecked everything else.
But now we're going to adapt this data slightly because some data needs to be public because this is a job board, and a job board has users, and users apply for jobs, and companies interact with job applicants, otherwise known as candidates. So we're going to be adding several rules to enable us permission to the correct data as we keep on building this out.
I'm going to show you the scratchpad page because this will give you further context into how these rules work. So here on the scratchpad page - I've adapted mine slightly just to show an image, so it's nice and clear - I'm currently Hana, [email protected]. Hana is the Current User because that's me - I have control, and I'm looking at my own data. So this user I'm looking at is Hana, and I'm the Current User.
So if we go back to this expression, "When This User is Current User," which is what we've just discussed is true, I'm looking at my own data, then I'm allowing the availability of all data from the server to be brought back to the page and available to Hana. This User is Current User. Got a little repeating group down here as well with the same data.
Now, in terms of the "Everyone else" section, now, obviously, this is a job board and there needs to be some public data. Otherwise, the public or even people with accounts can't see jobs, interact with jobs, everything is unavailable, basically. But we need to be smart about this. So just to give you an example, if I come back to this scratchpad page again, now, I've got a repeating group down here, and all I'm doing is a search for all users in the database, and I want their avatar, their name, and their email address. But I'm logged in as Hana, okay?
So now I'm going to say that I'm going to allow first names to be seen in the privacy rule under "Everyone else," so I'm going to click on "Name first". I'm going to allow them to be seen in a search. Check "Find this in searches." Now, if I refresh the page, now we've got two results. We have my first name because I'm also in the database, [email protected], that's my account. What if I said that avatars are also available? I'm going to check "Avatar." This is the "Everyone else" section of this rule. There's my avatar, because maybe I am an applicant to a job and Hana wants to be able to see my data. That's fair enough. And in that instance, maybe we would make the email address available as well but it would need to be a slightly smarter about that, so I'm going to leave that for now. So Hana can see my image, my name, but she can't see my email address. That's private. Only I can see my email address.
Why don't we log out as Hana and log in as me? And to save myself some time, I'm going to head down to All Users and use the "Run as" command. So I'm logged in, here's my email address, I am the current user. So This User is Current User, that's me. And now I can see Hana's first name, not her last name, and not her email address. So it's the inverse of what happened last time.
So that's a basic introduction to privacy rules. Remember, privacy rules enable access to data, not restrict data, because it's coming from the server to the page. So with that framework in mind, just remember, if you're creating a new data type or if you're adding new fields to data types, which you'll be doing throughout your build, always make it a habit to go back, make sure your privacy rules are protecting data that needs to be private. I'll see you in the next lesson.