71

Because the manual says it would.

As a bit of background on this. I am a native english speaker and I taught English as a Second Language for 10 years. My mind is such that I am a learner through books first, conversation second and video/image last. The text in the manual is clear, that the example condition of ‘current user is logged in’ is processed server side. The manual should be accurate as it is the only public source of how Bubble works that comes ‘from the horses mouth’ and I personally rely on it’s accuracy to help form my understanding of how Bubble works and allows me to use logic to form ideas of how to best build in Bubble and what types of features Bubble should implement to make building more efficiently easier, as well as to not incur costs that can be avoided based on my decisions about how to build.

In case you missed it, this is the exact statement from the manual:

To make sure a condition is processed server-side, you can involve anything having to do with the database or user authentication. For example, Current user is logged in and Do a search for:count > 0 are both conditions that Bubble will query the server to process.

To help illustrate how that statement is interpreted by a person like myself who is quite literal and I believe words have meanings that can for the most part not be left open for interpretation, here are five other ways this can be written provided by ChatGPT:

Here are five rewritten versions of the sentence:

  1. To ensure a condition is handled on the server side, you can incorporate elements related to the database or user authentication. For instance, “Current user is logged in” and “Do a search for: count > 0” are conditions that Bubble processes on the server.
  2. Server-side processing of a condition can be achieved by including aspects tied to the database or user authentication. Examples include “Current user is logged in” and “Do a search for: count > 0,” both of which Bubble evaluates on the server.
  3. To guarantee a condition is processed by the server, include features involving the database or user authentication. For example, “Current user is logged in” and “Do a search for: count > 0” prompt server-side queries in Bubble.
  4. If you want a condition to be processed on the server, make sure it involves database operations or user authentication. Conditions like “Current user is logged in” or “Do a search for: count > 0” will trigger server-side processing in Bubble.
  5. To make sure Bubble processes a condition server-side, tie it to the database or user authentication. For example, “Current user is logged in” and “Do a search for: count > 0” are handled by the server.

All of these statements, the one from the manual and the 5 rewritten examples by ChatGPT seem to imply pretty clearly in no uncertain terms that the condition of ‘current user is logged in’ will be evaluated/processed server side. In that statement there is not ambiguity and is not possible to be open for interpretation.

So @adamhholmes and @georgecollier would you guys say that the manual is either incorrect or not clearly worded based on your understanding of how the conditional evaluation of a condition like ‘current user is logged in’ actual works?

Now, to help illustrate this further, once I use ChatGPT to read the entire page in the manual found at this link I get a more clearer view of the issue here. What ChatGPT says is ‘current user is logged in’ is not always processed on the server (which would point to the manual being inaccurate or written in a way that obviously can cause confusion for some people), while the condition of 'do a search for count >0 is always processed via the server.

Question 1: If I use a condition like ‘current user is logged in’ on a client side action, will the condition be processed on the server?

Response: No, if you use a condition like “Current user is logged in” on a client-side action, it will not be processed on the server. Client-side conditions are evaluated within the user’s browser, which means the processing happens locally rather than on the server.

For conditions to be processed on the server, they typically need to be tied to server-side elements, such as database queries (e.g., Do a search for: count > 0 ) or workflows explicitly designed to run on the server. The “Current user is logged in” condition can be evaluated either on the client or server, depending on where and how it’s implemented, but in this case, a client-side action will evaluate it on the client.

If you want the condition to be evaluated securely on the server, you should integrate it with a server-side workflow or database-dependent logic.

Question 2: If I use a condition like ‘Do a search for: count >0’ on a client side action, will the condition be processed on the server?

Response: Yes, if you use a condition like “Do a search for: count > 0” in a client-side action, the search itself will be processed on the server, even though the action is client-side.

Here’s why:

  • Database-related conditions: When a condition involves querying the database, such as checking if a search result count is greater than 0, Bubble will process the search query on the server. The server handles the query to retrieve or count the data from the database, and the result is then returned to the client for evaluation.
  • Security considerations: Even though the query is processed on the server, the logic and subsequent actions after evaluating the condition are still executed client-side. This means sensitive information or business logic should not rely solely on client-side validation for security.

To summarize, the search query (Do a search for: count > 0 ) is processed server-side, but the overall action remains client-side. If you’re concerned about security or integrity, ensure that sensitive conditions are handled as part of server-side workflows.

So in my quest to understand what is the most secure condition to use, one that can be used universally on every trigger event that may contain a server side action, I personally want to understand this 100% and not half-heartedly. One of the reasons why I want to put the conditions onto the trigger event instead of the action step itself is to avoid bloat, as many times a single event trigger will have multiple server side action steps involved in the series, so adding the condition to each action step in the series is nonsensical to me personally, and I’d rather just put the condition onto the event trigger and not worry about trying to secure each individual workflow action step as that would be more tedious, time consuming and prone to error as it is more likely I may forget to secure one of the action steps, especially since in the view of workflows I do not see at a glance the conditions of every action step but I can for every event trigger.

So, again using ChatGPT to get a better understanding of this, it seems that the manual can be updated to be more clear and based on ChatGPT responses, more accurate.

Question 3: What is more secure, a condition of ‘current user role is admin’, ‘current user is logged in’ or ‘do a search for count>0’?

Response: The security of these conditions depends on how they are processed and the context in which they are used. Here’s a breakdown of each:

1. Current user role is admin

  • Processing: Evaluated client-side unless explicitly tied to server-side logic.
  • Security Level: Moderate to High, depending on implementation.
    • If this condition is purely client-side, it is less secure because a determined user could manipulate client-side data to bypass restrictions.
    • If the role verification is tied to a secure server-side workflow or privacy rules, it can be secure.
  • Use Case: Best when combined with server-side validation, especially for critical operations requiring admin privileges.

2. Current user is logged in

  • Processing: Usually evaluated client-side.
  • Security Level: Moderate.
    • While checking whether a user is logged in ensures authentication, it doesn’t provide authorization. A logged-in user might not have the necessary permissions for a particular action.
    • Secure if combined with other conditions (e.g., role checks or database queries) evaluated server-side.
  • Use Case: Basic checks to ensure a user is authenticated before granting access.

3. Do a search for: count > 0

  • Processing: Server-side.
  • Security Level: High.
    • This condition is inherently processed server-side because it involves querying the database. As a result, the logic and data verification are handled securely on the server.
    • However, the security also depends on how you configure privacy rules for the data being queried. Ensure users can only access data they are authorized to see.
  • Use Case: Ideal for secure verification of conditions involving database records (e.g., checking if an admin record exists).

Which is more secure?

  • Most Secure: Do a search for: count > 0
    It is inherently processed server-side, making it more secure against client-side tampering. Privacy rules add an extra layer of protection.
  • Next Best: Current user role is admin , when implemented with server-side workflows or checks. It ensures authorization but can be vulnerable if handled entirely client-side.
  • Least Secure: Current user is logged in
    While useful for basic authentication, it doesn’t address authorization and can be bypassed in client-side-only implementations.

Recommendation:

For maximum security, combine these checks server-side. For example:

  • First, confirm Current user is logged in .
  • Then, verify Current user role is admin or use Do a search for: count > 0 to validate permissions.

Always ensure sensitive conditions and data processing happen server-side to avoid manipulation risks.

So it seems that @adamhholmes and @georgecollier are correct that ‘current user is logged in’ or ‘current user role is admin’ are secure when placed onto a server side action or in a event trigger that contains a server side action step in the workflow series. The attempts to explain this to me were unsuccessful as I was focusing solely on the event trigger condition rather than on the action itself, and my reliance on the manual for accurate and clear explanations, since the manual as has been pointed out implies that ‘current user is logged in’ is used to ensure server side processing of the condition.

I am a professional Bubble developer and educator. I want to be a consummate professional and be fully capable of answering student or client questions as they relate to all things Bubble. At times I don’t know something off the top of my head I might refer to the manual for guidance. I personally do not want to provide tips, educational content or guidance to clients that is wrong or inaccurate, so for me, it is important that I understand this fully, complete with all of its potential ramifications.

So, although the issue was not 100% devoted to the costs of the conditional evaluation, since we now live in a world where WUs are a thing, I personally find it important to know the ramifications as related to WUs no matter how small the total WU cost of the conditional evaluation is, and if I didn’t know this information for my students or clients, I’d personally feel as if I was providing a disservice to them if I was unable to answer their potential questions about WU costs related to the conditional evaluation.

Also, important to know the WU implications, again no matter how small or insignificant on an individual basis, because not every client in Bubble is attempting to build an MVP and then leave Bubble. Some are going to scale with Bubble and until they reach the point of being on an enterprise plan at a cost of $3,500/month (paid annually?) then WUs will continue to be something they are paying for.

Another reason why it matters. A potential feature request to make securing our apps even more easily. We have privacy rules that can already protect most server side actions (at least Read, Update and Delete), so using conditionals to protect server side actions or data retrieval seems a bit redundant, and if it is a bit redundant it would be even more so to use the same type of condition to secure the action as what is already in place for Privacy Rules, so for me personally, the use of ‘do a search for: count>0’ is a better choice for the condition to protect the actions than ‘current user is admin’ because why not use two different ‘keys’ to unlock two different doors, instead of a single skeleton key for all doors.

Screen Shot 2024-12-24 at 1.01.41 PM
Screen Shot 2024-12-24 at 1.01.41 PM1351×115 10.1 KB

So the above screen shot, if I want to protect server side actions focused on make changes to thing or delete thing, I can simply uncheck the box of ‘find this in searches’ and with that, I protect not only against the Read of the data, but also the modification and deletion of the data. However, critically this doesn’t protect against the creation of data, except via the API.

This leads me to logically assume that if I want to leverage Privacy Rules more to protect data and related actions, perhaps I could just use the data API for all create actions and not bother with the built in Bubble create a new thing workflow action step, since privacy rules can protect against the creation of data via API but not via a workflow action step.

So, potential feature request:

  1. Make it so privacy rules can protect against the creation of data, not just the retrieval, modification or deletion.
  2. Allow for universal conditions…an area where we can craft conditionals like ‘do a search for: count>0’ or any other conditional that somebody might choose to use, that are universally available in the app, and can be applied to the event triggers, workflow action steps via a checkbox and a dropdown to select which condition to apply. If there is this universal condition feature, we can apply it to ALL workflow event triggers and know that ALL workflow action steps are protected if they are server side, and if the workflow series the universal condition is applied to doesn’t contain any server side actions, than the conditional doesn’t cause unnecessary consumption of WUs, again, no matter how small that cost may be on an individual basis.

Hope this clears up the confusion on why something is important for me to understand and all the downstream implications of my understanding.

1 Like