Do Privacy Roles/Rules make your pages load less quickly?

Hey everyone,

Been applying privacy roles and it appears that dynamic data seems to load slowly compared to when there were no restrictions. I have admin roles that can view everything, and user roles that can only view things created by them or things that are stored on the user. I have tested the speed by switching my user between admin and regular, and it is clear that the Admin view is faster. I would think the reverse would be the case since it is loading less data.

Is this something other people have observed? If so, do you have workarounds you usually put in place?

It’s normal to expect that privacy roles would have some impact on performance.

For that reason, it’s good to examine a) how much data you’re trying to initially load and b) if your privacy roles are overly complex.

For example, if you have a repeating group that is based on a “Do a search for X” that doesn’t have much constraints and is loading a full list, that may slow things down considerably. So, good to ensure you have well constrained searches (and not overly reliant on filtering).

Think of your privacy roles like a request going through a series of pipes - some are more direct routes than others. Bubble is going to evaluate all of your privacy roles to see if there is a “match” that grants access to the requested data. (So, the is current user admin = yes role is going to evaluate faster. But your other roles may take more time to evaluate.

In some cases, it may be better to work with pre-defined lists. (Ex. for a property rental site, save a list of properties owned by the current user on the Current User. That way, you can enforce a privacy role that is “Current user’s properties contains this property”).

Some initial thoughts. I’m sure others will chime in.


Dan (creator of LearnTo - 15+ hours of Bubble tutorials and live coaching)

5 Likes

I was also reading over @josh’s post here: Josh: Request for a Security Q&A Guide - #18 by josh. Adds some good context.

How do privacy rules work?

Privacy rules are the primary tool in Bubble for specifying who ought to be able to see what data. When designing an application, you should think through, for each kind of data your app will store, who ought to be able to see it. Just the user who uploaded the data? The user and certain other users who meet specific conditions? The general public?

If the answer is not “the general public”, then it is important to create privacy rules. Think of each rule you create as a reason someone ought to be able to see a piece of data. For instance, one reason might be, “I’m the user who uploaded it”. Another reason might be “The user who uploaded it tagged me”. More information on how to set up and use privacy rules is in our manual: https://manual.bubble.is/working-with-data/privacy-and-security.html

Privacy rules get applied whenever your app searches for or retrieves data. Behind the scenes, we add them as extra constraints to searches: if you search for all users, what we really do is search for “all users who the currently logged-in user is allowed to see”. This applies to searches on a page, as well as searches inside workflows: whenever we are running a workflow, we track who the “current user” is, and only show that workflow data that is allowed by privacy rules.

The general rule of thumb is: if privacy rules allow someone seeing data, that person can see it. Don’t rely on hiding things on a page or redirecting to a different page to protect secure data, and don’t rely on not having built a search anywhere that returns the data. Those measures might stop someone from stumbling on data accidentally, but they won’t stop someone determined to view it.

If you need to modify data that the current user is not allowed to see, the best approach right now is to use a scheduled API workflow with the “Ignore privacy rules when running the workflow” box checked. This will run the workflow entirely on the server without sending data to the user’s web browser, and it will remove the restrictions on searches, so that the workflow can retrieve data that the user wouldn’t otherwise be able to access.

2 Likes

Thanks for the response. Yeah, I spent the past few minutes optimizing the rules and that definitely helped. I also ran a few more tests and it appears that much of the slow loading data could be attributed to filters on long user-stored lists. A constrained search for the same list on the other hand loaded really quickly.

Will re-evaluate some of the logic. Thanks again!

Of course, glad that helped!

Hi Dan, re: your answer above:

I have a repeating group doing a search for a thing. The result shows:

  1. the thing name
  2. the name of the person who created the thing
    Because the User privacy rule has a condition on it, the User’s name loads a second after the thing name.

I’m thinking of just sticking the person’s name into the thing data table as a text field so that it loads at the same time as the thing name.

Would this be the ‘right’ way to do this?
Thanks, Jess

PS. completely unrelated question - I’m not using a map in my app but there is a lot of red text in Settings telling me I should have a Google Maps API key. Do I need one if I don’t display a map image? I’m also not using browser location services but am using ‘x distance from user’s address they entered in a form’.

I would recommend against duplicating data. (Say, for example, that underlying user had a typo in their name. Then they update it on their profile. Now, all your text-based versions of that user’s name need to be updated. Otherwise it’d appear incorrectly).

Regarding Google Maps, you should get your own API key regardless. (Think about it like getting your wallet before you go to the store - you may not buy anything, but better to be prepared). You are OK without it, but Bubble strongly pushes you to get your own. Otherwise, with excessive use, I believe Bubble will start throttling your requests. (What that threshold is, I don’t know).

You can find my instructions video for setting up your own Google Maps API key many places on the forum.

Thanks Dan.

1 Like