Please share how you do it…I’m really curious how a condition that is checked on server is able to be bypassed. I can’t see any data being sent to the client device while watching the network tab in dev tools when I try to run the action and condition fails the check on the server, but I suppose I could be looking in the wrong place.
Is terminate workflow a server side or client side action?
Is that all of it?
Or is there more?
It can’t be.
But this is NOT a condition that’s checked on the server (that’s the bit you’re misunderstanding).
It’s checked in the Browser.
Again.. nothing is being checked on the server here - that doesn’t even make sense for client-side stuff like showing hidden elements.
Only server actions have conditions checked on the server.
So how is it done? If there is no network request and no element in DOM on page load?
As I said before, ALL of the required code to render all of the page elements (including those hidden on page load) is sent to the client when the page loads (as part of the main JS).
So no further network requests are needed (assuming no more data needs to be loaded).
The Hidden elements are added to the DOM as part of the Workflow that shows them(that’s what ‘show an element’ does - at least when the hidden element has ‘Collapse when hidden: true’ - otherwise it will already be in the DOM).
The page code exposes what the Condition on the WF is (current User’s Email is {your email address} - or something like that).
So then I just need to convince the app I’m a logged in User with that email address, which is done simply by overriding the Current User data in the browser.
Then, when the Button is clicked, the condition is checked in the browser, the logged-in User’s email matches that stated in the condition, and so the condition is passed and the WF runs.
For the Data API calls, Bubble will still evaluate conditions/parameters on the data request (e.g. the server value in one of the parameters), even if these are changed client side - at least I believe that’s the case, have you found anything to the contrary @georgecollier ?
Thanks for explaining that.
Is this something that most JavaScript sites would be vulnerable to. My assumption is any JavaScript site on other platforms have to get the code sent over to browser on first load, and that’s just the way things are.
Or, is there something that bubble could do to alter this without affecting performance?
Well, Bubble could use Server Side Rendering - but it doesn’t, and that’s not how Bubble works at all (Bubble servers don’t send fully rendered HTML from the server - it’s constructed in the browser by the Bubble engine).
But, it’s important to re-iterate that this is NOT a security vulnerability nor a security concern at all (as long as you don’t make it one).
Security (In Bubble) is correctly handled with:
Things like hiding/showing elements on pages, or using popups, alerts, and other on-page stuff are all just additional UX features - not part of any core security (As can all be very easily bypassed).
You could create a “page data” type and set privacy rules on it and use this exclusively for all “static data.” The question is, is it worth the tradeoff of worse UX (increased latency + things shimmering/shifting) and higher WU. Not sure how this compares to other stacks, but that’s at least one option.
My experience is contrary to that (I just ran a test of this).
It seems, when using an API Data source, Bubble uses the Client Side data to evaluate any conditions AND for use in the API call parameters - even when the ‘Attempt to make call from the browser’ options is NOT checked (meaning the API call is made from the server).
e.g.
I set up a RG with a conditional API (GET) datasource, the condition being when the Current Users Admin = Yes. (with ‘Attempt to make call from the browser’ set to No).
I ran it with a User with ‘Admin: No’, where the API data does not load (as expected) and then override the User data in the browser (changing their Admin field from No to Yes), and the User was able to access the data from the API call.
I also used the modified User fields in the API call parameters and, again, it was the modified Client-Side version of the User data (not the User data as saved in the DB) that was use in the API call.
So, at least from this test, it appears that API calls use client-side Data in any conditions AND parameter values (even when ‘Attempt to make call from browser’ is NOT selected).
It partially depends on the type of headers you use for that call too.
But this is why we tend to not recommend using API calls as data in the front-end.
It seems adding any type of auth to the call DOES force Bubble to use the Server Data in the API call parameters.
BUT.. it still uses the (modified) client-side data in any conditions on the datasource itself.
Is there a set of solid rules, a playbook so you will how to setup certain security conditions related to a desired outcome (e.g. 1. nothing on the page is loaded –> no DOM loaded when Current User is not User 2. elements aren’t loaded (is this possible?) 3. elements cannot be triggered, 4. data is not loaded etc.)?
The truths you need to know are:
Ok thanks! @adamhholmes and @georgecollier - just to corroborate some findings with the Data API call.
Would that be correct?
Also in case of a redirect on the page?
