Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 41

Admin-Only Management Page Access

Recommended resources

Hello! In our last lesson, you built a powerful admin page with forms to create, edit, and delete tools from your database. This was a massive step towards your goal of creating a scalable multi-tool platform. However, right now, that admin page is only protected by obscurity. We need to add robust security to ensure only you can access it.

Today, our learning outcome is to set up privacy rules to ensure only admin users can access the management page. We will implement two critical layers of security: first, we'll block non-admins from even loading the page, and second, we'll use Bubble's powerful server-side privacy rules to protect the underlying data itself. This will make your admin panel truly private and secure.

For someone with your background in WordPress, this is analogous to how WordPress protects the /wp-admin area. It doesn't just hide the login page; it uses a system of user roles and capabilities to control who can see what and who can do what, all enforced by the server. We're about to build that same level of control in Bubble.

Part 1: Defining an "Admin" User

Before we can restrict access to an admin, we first need to define what an admin is within our app's database. The simplest and most effective way to do this is by adding a new field to the built-in User data type.

  1. Navigate to the Data Tab: Go to the Data tab and select the User data type.
  2. Create a New Field: Click "Create a new field".
    • Field name: isAdmin
    • Field type: yes / no
    • Default value: Click the box and select no.
  3. Click Create.

By setting the default value to no, you ensure that any new user who signs up for your platform will not be an admin by default. This is a crucial security-first practice.

Now, you need to make yourself an admin.

  1. Go to App Data: Still in the Data tab, click on the App data sub-tab.
  2. Select All Users: In the views on the left, click on "All Users".
  3. Edit Your User: Find your user account in the list and click the pencil icon to edit it.
  4. Set isAdmin to "yes": Find the isAdmin field and change its value to yes.
  5. Click Save.

You are now officially the first administrator of your platform!

Part 2: Page-Level Security

Our first layer of defense is to prevent non-admins from even viewing the admin page. We can achieve this with a simple workflow that runs every time the page loads. If the user is not an admin, we'll immediately redirect them away.

The article "How To Create An Admin Role in Bubble" from Nocode Assistant provides a clear guide on this exact technique.

How To Create An Admin Role in Bubble & Grant Privileges

This article explains the standard method for restricting page access based on a user's role.

Focus on the section titled Restricting page access. This part details how to create a "Do when condition is true" workflow that checks the user's role on page load and redirects them if they don't have permission.

Let's implement this on your admin page.

  1. Go to the Workflow Tab: With your admin page open in the editor, navigate to the Workflow tab.
  2. Create a New Workflow: Click the empty box to add a new event, and choose General > Do when condition is true.
  3. Set the Condition: In the workflow editor, set the condition to run Only when Current User's isAdmin is "no".
  4. Add the Redirect Action: Click to add an action and select Navigation > Go to page.... Choose your index page (or any other non-admin page) as the destination.

This image shows the logic you're building. When a certain condition is met (in our case, the user is not an admin), an action is triggered to navigate them away.

This workflow demonstrates how to restrict page access. When the page loads, it checks the user's privilege and redirects them if they are not an admin.

Now, if a non-admin user ever gets the direct link to your admin page, this workflow will instantly send them back to the homepage before they can see or do anything.

Part 3: Data-Level Security with Privacy Rules

Page-level security is a great start, but it's not enough. A sophisticated user could potentially still query your app's database and retrieve data if it isn't protected at the source. This is where Privacy Rules come in. They are conditions enforced on the Bubble server, making them the ultimate gatekeepers of your data.

The Bubble documentation and an official tutorial video offer a comprehensive overview of this crucial feature.

How to Setup Privacy Rules | Bubble Tutorial

This official Bubble tutorial explains the 'why' and 'how' of privacy rules.

Please watch the following segments: The introduction explains why privacy rules are essential for security. This section details how to create a rule, define conditions, and grant permissions. Pay close attention to the concepts of Current User and This thing. The example on securing user data demonstrates the exact pattern we will use: one rule for the owner (This user is Current User) and a restrictive rule for Everyone else. Finally, watch the segment on additive rules, which explains how multiple rules (like 'employee' and 'admin') can work together. This is directly applicable to our admin setup.

Now, let's dive into the Bubble documentation to see the exact structure for an admin rule.

Protecting data with privacy rules

This is the definitive guide to privacy rules in the Bubble manual. It explains the core concepts and provides a perfect example for our use case.

First, read the introduction from the beginning down to the illustration to understand what rules are and why they are server-side. Next, read the section How privacy rules work to understand the different permissions (like 'Find in searches') and how rules are constructed. Finally, study Example 1 very carefully. This example, which uses a Shopping Cart data type and an Admin field on the User, is a perfect parallel to what we need to do for our Tool data type.

With that knowledge, let's build the privacy rules for your Tool data type.

  1. Navigate to Data > Privacy: In the Data tab, click the Privacy sub-tab.

  2. Select the Tool Data Type: Find Tool in the list of data types.

  3. Define the Admin Rule:

    • Click + Define a new rule.
    • Rule name: Give it a descriptive name like Admin Access.
    • When: Set the condition to Current User's isAdmin is "yes".
    • Permissions: Check all the boxes: View all fields, Find this in searches, View attached files, and Allow auto-binding. This gives admins full control.

  4. Define the "Everyone else" Rule:

    • This rule is present by default at the bottom. It applies to any user who doesn't meet the conditions of the rules above it (i.e., all non-admins).
    • Permissions: Uncheck every single box. This is the most important step. It ensures that if a user is not an admin, they are granted zero access to the Tool data.

Your final setup should look just like the example in the Bubble documentation, which is captured in the image below. You will have one rule granting full access to admins, and a default "Everyone else" rule that denies all access.

This image shows the correct privacy rule setup. The "Admin user" rule grants full permissions, while the "Everyone else" rule has all permissions unchecked, securing the data from non-admins.

You have now fully secured your admin functionality.

Conclusion

In this lesson, you've implemented two essential layers of security to protect your admin page and its associated data. This is a non-negotiable step for any serious application, and it's a core skill for building the robust multi-tool platform you envision.

Here are the key takeaways:

  • User Roles: You can define roles like "admin" by adding a yes/no or Option Set field to the User data type.
  • Page-Level Security: A Do when condition is true workflow on page load is an effective way to redirect unauthorized users.
  • Data-Level Security: Privacy Rules are the most secure method of protecting data as they are enforced on the server.
  • Granting, Not Prohibiting: The core principle of privacy rules is to grant access to specific roles. The Everyone else rule should always be set to the most restrictive permissions (usually, none).

In our next lesson, we will build upon our secure admin panel. Now that you can safely manage your tools, we will create a workflow to publish or unpublish tools from the live site, giving you fine-grained control over what your end-users can see.