Best Practices for Managing Access to Pages Requiring a Login

I’ve read a number of forum posts in an effort to get a handle on how best to structure my pages and manage access control. My app will allow users to log in to manage their account, follow other users, etc.; and from what I’ve read, Bubble best practices for controlling access to pages intended only for logged-in users involves the following:

  1. Creating a “master” group to hold all elements of any page intended only for logged-in users
  2. Setting that group to “not visible on page load”
  3. Performing the necessary permission checks in the “Page is loaded” workflow (which could be as simple as “Current user is logged in”)
  4. Showing/revealing the master group if the permission check succeeds, or redirecting to another page if it doesn’t

Is that correct?

Given that this is [presumably] a common scenario for a membership site, is there a way to hide the page element itself instead of having to create a containing group each time?

Is there any way to issue a 404 (page not found) or 401 (unauthorized) response instead of a redirect for non-logged-in users attempting to access the page?

(Also, I understand that robust data access roles are important, but I’m wondering specifically about best practices for dealing with pages and the UI.)

Any corrections, suggestions, or insights appreciated!


You basically got it (and summarized very well!).

As for the issue of the “master background group”, what I do is have sort of a template page that, when I start a new page, I use as the source (e.g., copy from page “blank”).

Or just start from any existing page that has that set up already (and is simple enough that deleting existing elements isn’t a huge P-I-A.)


1 Like

Oh yeah, of course. Thanks for the tip!

1 Like

I have a follow-up question…

So let’s say there are a number of buttons on the page which trigger workflows. Should I be checking if the user is logged in for each workflow before running it? In other words, would it be possible for a malicious non-logged-in user to run a workflow if they discovered the proper request/URL to send?

The workflows perform actions only on the current user, so it seems like it’s unnecessary, but I want to be sure.

In general, no you should not worry about that.

There are caveats. They are too hard to explain. Basically, just don’t have interface elements lying around that can be used to do something like execute an API Workflow that runs in the context of the server (that is “ignore privacy rules when running this workflow” is checked) that do things like:

Step 1: Delete a list of things… things of what type? User. What list of Users? Do a search for… Users (unconstrained).


1 Like

Not really necessary to say if user is logged in on each workflow as long as you think of all the potential scenarios and block the ones that have security flaws. Good testing, good logic as well as data privacy roles should suffice. If you are concerned about something, test it and see if you can “hack” your own app. Then block yourself out. You know your app better than anyone else.

That’s why hackers are the best security guys because they can think of all the possibilities to guard against. Even Apple has security flaws such as the recent FaceTime spying hack. Just be quick to fix it. :slight_smile:

That’s my opinion. Others can chime in too to explain in more detail and other ways to help. There are a lot of different ways to protect your data.

Gasp! Be right back, I need to go change a scheduled API. :wink: Just kidding.

1 Like

I know this is a very old topic…

I have used this information on my app, but stil I do have some doubts…

When page is loaded and current user role is “NO ACCESS”:
It sounds weird to first download the page to the computer and that say: sorry you do not have the rights to see it?
I’m not a hacker, but it sounds not ok…

Is there an option to prevent loading if the role is “NO ACCESS”?
BEFORE page is loaded and current user role is “NO ACCESS”?

Or do I see to many ghosts here?

Thanks for your reaction

Perhaps you’re already aware, but privacy rules should be your first line of defense to prevent viewing of sensitive data.