Bug? - Privacy Rules and Page Content Type

Bugs
1

I have privacy rules that function fine. But, seems like there is a bug that when the page is loaded with the content type set and the user is logged out, after logging in and matching criteria for privacy rules to expose the data, the data is still not exposed until I do a refresh of the page.

I do not recall this ever being the behavior, as I recall it as once the user logs in the data is available only if the user matches privacy rules applied to the page ‘thing’. Now, it seems like there is a bug that forces us to do a full page refresh in order for the data to be available.

1 Like
Init/data returns records without login — how to fully lock it down?
2

This has got to be a bug. Absolutely, no question about it, this is a bug.

When I am unable to figure out a workaround, it is a bug. When any workarounds pose significant issues, it is a bug.

Only things that I can think of in order to do a refresh of the page via an action as soon as the user logs in, is to firstly, make the data less secure by having to expose to everyone (ie: no privacy rule basically) the field that is the ‘user’ who should have access, that is a privacy concern, but with this BUG, I need to do that just so that we can evaluate properly after log in if the current user is the user who should have access.

Then if I want to after the user logs in, to refresh the page via an action, I can use ‘page is loaded’ event, but that won’t work because the page is loaded event is not firing as soon as the user logs in. So the next trigger I can use is a ‘do when condition is true’ and set that condition to be ‘when current user is page thing ‘user to access’’ and run that just once and do a page refresh, BUT we get stuck in an infinite loop of the page detecting the condition is true and refreshing page continuously.

I could make it so that after every single login the page is refreshed, but why, why in the world would I have to do that? Just so that I could get charged DOUBLE WUs for every page load that a user then logs in from? Makes no sense and I do not believe Bubble has that intention.

Please let me know if I am just an idiot and completely incapable of figuring out how to ensure that on log in the user has access so long as they match privacy rules, or if this is not the correct behavior and this is in fact a BUG that is causing major issues with privacy rules and the access to data. @fede.bubble I have submitted an email to bubble to request confirmation on whether this is some sort of new ‘feature’ or an actual Bug.

3

From what I know, privacy rules when a page has data type are evaluated on page load, when bubble does the data call.

When the user logs in, the state of the user is changed but the fetched content remains the same unless you re-run the data call to re-evaluate the rules against the new “current user”

4

So how do you in your apps deal with a situation where, there is a page with content type, that page is going to be navigated to directly with a unique URL for that content type data entry to be displayed.

The privacy rules of that content type are such that a user must be logged in to view the data and the user must be the user on the related field of the content type.

So, what do you do in your app to re-evaluate the rules against the new ‘current user’? Are you making it so you run actions that are conditions, or page load actions?

The thing that is the BUG is that BUBBLE is not re-evaluating the rules against the new ‘current user’ for us as they ALWAYS have over the past 7.5 years as far as I can remember, but I know my memory is not perfect. SO, I’m looking for the answer to how to account for this.

As mentioned, the only ways I can think of to account for this do not work. Page load action won’t work because Bubble is not ‘reloading’ the page (reloading is different from refreshing - especially with consideration of page is loaded action triggers), and I ultimately believe that is the issue, since whenever the bubble_session_uid is changed, that should ‘reload’ the page and therefore allow for an immediate ‘re-evaluation of the current user’ but that is not happening right now.

The other workaround I can think of is the do conditional trigger, which as mentioned results in an infinite loop of page refreshing and refreshing and adds privacy concerns through a need to expose the User to everyone just so that I could do the evaluation of the condition.

So what are you doing in your apps? Are you just refreshing the page after every login, resulting in another 0.15WUs for page load and any WUs for fetching of the data again?

Surely there must be a way to make this work that doesn’t cause privacy concerns, nor incurs extra WUs if this is not a Bug.

5

I can not even setup a conditional event trigger on page that says ‘when current user is logged in and current page field is empty’. When data privacy rules are in place, any data fields that are not accessible are evaluated as ‘empty’ (look at debugger) but when I use this conditional event trigger, it doesn’t trigger even though the debugger is evaluating the field as empty, there is not id for the field displayed on the page and the evaluation of ‘is empty’ done via text element shows as if it is empty. BUT my workaround attempt for conditional evaluation of ‘current user is logged in and current page thing field is empty’ is not firing.

This has never been the case, and it wasn’t like this just two days ago.

Another bug is that when the user is logged out, the secure data is still visible.

Seems like Bubble is not updating user sessions properly on login and logout.

6

@boston85719 normally you can handle these situations with an /auth page with a nice loading spinner, both for logged in and logged out users.

You’re right in that attaching a thing to a user (e.g. this User’s Thing is Thing > Privacy rules open). But this has always been the case (although not ideal).

So the flow would be:

  • Load the auth page
  • Attach the thing
  • Load the end page
7

I do not believe this has always been the case, especially because I’m seeing issues that Privacy Rules are completely ignored. I made a video to document what I am experiencing with this Bug.

My privacy rules require the user to be logged in. When a user is logged out, via the log the user out action, I have setup in the app for them to be navigated away from any page they are on, and to go to the index page. Now, this BUG, is causing it so that when the logged out user, presses the back navigation on their browser, ALL of the Private and Secure data is STILL ACCESSIBLE even though NONE of the privacy rules are being matched to make it so that the data should be accessed.

Seems to me like a major Bug that is a HUGE privacy concern. No way as it always been that a user who logs out could then just use back button on browser to continue to view secure/private data. In the 7.5 years on Bubble I have never seen that.

@georgecollier are logged out users suppose to be able to access private/secure data by pressing the browser back button like in the video below?

I’m not attaching the ‘thing’ to the user. I already have attached to the page ‘thing’ a field that is related to a User and the User that is supposed to access the page ‘thing’ is already filled in at the creation of that ‘thing’.

8

In that case you might be dealing with back/forward cache Back/forward cache  |  Articles  |  web.dev

9

I’ve watched the loom and will just list the points I thought about going through (some may be relevant, some not, but you can be the judge based on your use case)

  • The expected behaviour has always been that privacy rules that relate to Current User evaluate on hard page load.
  • So, the comment made at 1:25 in the Loom isn’t strictly going to be the case all the time. Updating the user happens after the page is loaded.
  • Your top privacy rule is redundant, because the “owners” rule grants permission regardless of whether they’re logged in or not and as you know, privacy rules are permissive.

This topic was touched on in this thread and @adamhholmes’s reply will be helpful:

10

Thanks for the response. Please check out the other post where I provided a simpler example and app editor to see the setup.

My concern is that the ‘go to page’ action is not doing a page is loaded action to actually do a hard page load, so that action is useless, and instead I need to do a page refresh. With the page refresh, there is nothing available to evaluate against that would make it possible to do the page refresh without going into an infinite loop of refreshing the page.

Even when I run a go to page action to go to the same page and send in a parameter, there is no new page load (the action trigger does run) that causes the data privacy rules to be re-evaluated.

I’ve always experienced it where once a user is logged in or logged out, the privacy rules are evaluated, but that seems to not be happening now. But maybe I’m wrong and Bubble never had the smart feature of doing that?

I’m not updating the user data at all.

Added during this testing to try and figure out why the privacy rules are not being adhered to, especially when the user is logged out.

Think about this.

  1. Page with content type and privacy rules that require the user to be logged in. User is on this page and logged in and so the data is accessible.
  2. User runs a log out action, which the app, logs the user out and navigates them to a new and different page.
  3. User presses back button on browser and returns to the ‘protected’ page and is logged out; BUT the data is still accessible.

Is that situation I just described expected behavior? If seems that a browser back button press will do a ‘hard page load’ since it is navigating to a new and different page from which the user is currently on. In the app I encountered this on, and the test app I created and shared on other thread, this is happening and seems like a major security concern.

Does Bubble not run privacy rule evaluations when the current user changes? If not that is ABSOLUTELY BONKERS. If my current user unique ID changes, the privacy rules should be re-evaluated at that moment, because that is the moment a NEW SESSION is created which results in a new bubble_uid_session. So why is it that when a current user unique changes and the session changes are the privacy rules not getting re-evaluated. That is CRAZY TOWN BUSINESS to me.

11

Go to page, then refresh the page with two actions and a condition on Go to page that is always true.

Yes you are, by logging in / logging out. I mean the session, by the way, not specifically the fields on the user.

It does.

It certainly would be, if it were true.

12

So you are saying then that privacy rules are re-evaluated when the user logs in and logs out, but the data is not getting re-fetched or removed from cache?

This seems like CRAZY TOWN BUSINESS to me that Bubble is not removing from cache previously downloaded data, especially if they are re-evaluating privacy rules when the user changes and those privacy rules would not allow that current user to access the data.

This seems like an issue.

I guess the work around is going to be a link to a different page for logging in, then a redirect to the page with the protected data (nice, now I have to load the page twice), so the the data is fetched only when the user is actually already logged in, and then on log out a navigation away from page with a clear history from browser so it is not possible to use browser back button which would allow the user to access protected data that is saved to cache.

Is there a way for us to clear the cache via an Bubble actions?

Or just put some groups with conditions based on user is logged in, so when those groups are or are not visible I can just run conditionally triggered actions of refresh page.

Somebody at Bubble should setup things so that the data is removed from cache if privacy rules no longer allow for that data to be accessible.

1 Like
13

So maybe this is not a Bug and maybe it is expected/known behavior. Not very secure in my inexperienced mind, but my solution that I think is the cleanest for my desired UX. I want the link to be direct to the page, no other pages involved. I want the user to not be navigated away from the page after logging out BUT the protected data must not be accessible still.

I added a group called user logged in. With a condition that it is visible only when the user is logged in.

I have a conditional trigger to run only once, that is ‘when group current user is logged in is visible and page content field is empty’ to refresh the page.

I have a second conditional trigger to run only once that is ‘when group current user is logged in is visible and page content field ‘is not empty’ to refresh the page.

This allows me to not get the page stuck in an infinite loop of refreshing the page because I do not reference the current user is logged in, but instead a groups visibility. When I used the same approach but referenced the current user is logged in, it just goes to an infinite loop of refreshing and refreshing.

What a mess. So many things non-technical, inexperienced with web security people could find themselves leaking.

@georgecollier does NQU secure check against issues like this?

14

Thank you @akamarski seems like this is the issue related to why the data is still accessible after log out.

15

That’s just not true though. Anything sent to a browser, at least once, will ALWAYS be accessible to that user, because once it’s on the client, it’s fair game for the user to do what they want with it.

That’s exactly why these options exist on browsers where users might share a computer:

CleanShot 2025-08-31 at 19.16.52@2x
CleanShot 2025-08-31 at 19.16.52@2x1028×948 83.9 KB

This doesn’t work?

No, because the fact that a user can access data they’ve been sent in the past isn’t a Bubble issue. It’s just the nature of the web.

16

I am using the group visibility approach. I did not try your approach with two actions and a condition on the go to page, because the go to page action doesn’t do a hard page load and so even though I use the go to page action, it doesn’t remove the cached data. The only way I’m seeing the cached data removed is via a page refresh action.

I appreciate the help. This now has been exploring more about BFcache.

I have no idea of how the web works. What has been helping me in bubble most for security stuff, is thinking not about bubble, but learning more about just how the web works.

17

Go to page will update the page data source. Refresh the page will hard refresh it. A condition that’s always true on Go to page will remove the error that says ‘Go to page must be the last action in the workflow’

Keep in mind that conditions/logic that rely on group visibility can be easily manipulated so only use this solution if it’s just a UX thing

1 Like
18

I may be wrong but I remember that a couple of years ago data loading was updated again on login/logout of the user and all dynamic content was updating automatically. now if there is data loaded on the page it stays there after logout and not requested again to see if it should be available according to privacy rules. It may be because a different caching strategy of the data requests as it was said in the other topic.

19

It’s specifically because of using a page as a type of Thing, rather than loading it as a search/any other expression.

20

Thank you @dorilama for confirming I’m not crazy to believe it used to work as it would be expected to work. Makes me feel a bit better about my memory.

@georgecollier I came to find this out around 1:45AM last night as I was watching TV, so I went upstairs to test things out. Here is the video of that. Forgive how often I chuckle at the absurdity of this.

Basically what happens, as you explained in another thread or this one, is that when using content type on page that data is fetched on page load, and privacy rules are evaluated at that time, and since Bubble has broken the previously working functionality of re-fetching any necessary dynamic content when the session/user changes, it is not re-fetching the page ‘thing’.

Also, they are not clearing BFCache as they should on logout. That part is a bit ridiculous that they do not, but they have apparently chosen not to. That is a security issue that they should patch up by basically clearing that when a user logs out.

Either way, the sense of it being specifically of using a page as type of thing, that is sort of correct, but not the whole story and demonstrates the buggy/poorly developed features.

In the video above, what I find is that the loading of data as a search/any other expression, is not on it’s owning going to get the data re-fetched when session changes, so as to evaluate again privacy rules. In testing I can see that if we use the content type, there is no mget in network tab, ever. Not on page load, and not after user logs in. This I do not know why, but is likely related to the sense of the data is fetched once and not again.

So first test, was to put a group with a condition to set the data source and use the URL path list item#2 as the source of constraint to search for a ‘thing’ by unique ID. That is all the content type on the page does anyway. This proved that it is not just about using the page type thing. Instead it is a bug in how Bubble looks to the URL path list item #2.

So when I in the video start changing around the unique ID and position of the unique ID in the path list, I find that if I want the expected behavior, I can not use the path list item #2 to hold onto a unique ID. Watch the video, it is funny how ridiculous this is.

The best setup is to not use the content type, put a group to conditionally run the search for the thing by unique ID. Additionally, there must be a path list item #2 that is not a unique ID and instead something else like maybe ‘en’, and to put the unique id as path list item #3. With this setup the user can hit the page without being logged in, have the data protected twice (once with conditional to load the data source based on ‘current user is logged in’ and second by the privacy rules), then when the login from that same protected page with it’s own unique URL for the specific ‘thing’ to protect is completed, the data is fetched, privacy rules evaluated against the new user, and data is immediately available without a page refresh. Then on log out, the data is removed and is not left in BFCache so no concern about using the browser back button and still having the protected data visible.

Bubble needs to fix this as it is a security concern and they should just revert to previous behavior of updating the data on login/logout.

@DjackLowCode @akamarski I tagged you both here as you might be interested in the findings. It does have to do with BFCache, but to get desired behavior we do not need to do separate auth page and redirects.

1 Like