This issue is being fired when a page is defined as sensitive and it has no proper 302 redirection to ensure the data is safe and the page is never entirely loaded.

To illustrate this issue, consider the following scenario:

You have a page called "admin" that is restricted to users with admin access because it contains sensitive data such as private pictures of users, and allows admins to take certain actions.

In this case, you might want to check if the current user has the admin role and, if they do not, redirect them to the homepage. While this may seem like a logical approach, it is important to understand that redirections can be problematic.

It is essential to have a thorough understanding of how redirections work to avoid this type of issue.

When you try to load a page, you are making an HTTP request to the Bubble servers to retrieve the content of the page. The response from the server can be one of five different types:

As you can see, there are multiple possibilities for redirection codes within the 3rd category. The most important thing to understand about redirection is that if you receive a 3xx response from the server, no content will be downloaded and you will be immediately redirected to the next page.

This is known as a "server-side redirect."

In contrast to a server-side redirect, a "client-side redirect" is a manual redirection that is initiated by a JavaScript instruction. It is important to note that JavaScript needs to be downloaded before it can be executed. This is how a client-side redirect works:

The admin page is downloaded, and then JavaScript is executed to tell the browser to go to another page. However, by this time, all of the data has already been downloaded, making it too late to prevent unauthorized access.

It is important to be aware of the limitations of client-side redirects and to use appropriate security measures to protect sensitive information.

To set up server-side redirections, you need to use the "Go to page" action without relying on any client-side conditions or events. For example, you could set up a redirection using the « User is logged out" to see what happens. Let’s see what we get:

To verify that you are correctly using a server-side redirect, you can use a redirect checker such as this one. This will allow you to determine whether you are receiving a 3xx or 2xx response from the server.

We indeed have a 302 redirect on the page « redirect », then we’re redirected to the page « index » which is fetched with a 200 code.

All good!

Let’s try another method and use a client-side condition. We will use the « Do when a condition is true » event (that gets executed once the page is loaded), and check if the Current User is an Admin or not:

Let’s check the response code from the redirect checker:

We got a 200 code. This indicates that the page has been completely downloaded and that no server-side redirect has been applied.

Let’s resume client-side and server-side redirections for main events:

Caution: if you add a client-side condition on a server-side redirection, the page will wait for the client-side condition to be checked and then apply the redirection. Your safe redirection will not be safe anymore.

In order to define a proper server-side redirection, you have to create a redirection based on :