To provide some context, any dynamic expression related to user authentication, such as User is logged in, would use workload units because authentication is managed on the server.
Using a conditional on a button click like in the screen shot above, ALWAYS results in a 0.020 WU charge for ‘individual data request’ no matter what actions you have in the event…whether those actions are make changes to thing or a client side action like ‘show alert’.
The only types of conditionals to use for security in order to ensure a workflow action is not accessible by a bad actor, would be a conditional that is a server side evaluation. Any client side evaluations like ‘current user role is Admin’ are not going to help with security in any way since a bad actor can change their role client side.
In reality the best conditional to use for security on a workflow trigger event is do a search for user: constraint 1. User email = current user email; constraint 2. User role is admin: count >0
That condition will force a server side evaluation because of the do a search, it will check a field on the user data type that is impossible to change client side (the email field).
So the condition in the example above of ‘current user is logged in and role is admin’ is not secure at all since the role field can be changed client side or directly in the database by a bad actor.
I’m pretty sure, for sever side actions, that condition is evaluated on the server (as it should be). My own testing certainly confirms that to be true.
So Current User is Admin AND Current User is logged in isn’t safe because of this exploit? This was supposed to be investigated by Bubble’s team but they never got back to us in the original thread. Or are you just referring to the known exploit about how Current User is Admin is exploitable without the “AND Current User is logged in?”
A person can alter the values that are in the DB, and therefore, the server side conditional would evaluate based on the values in the DB that were altered.
What about the 0.2 WUs?
It is not because the Current User is Admin can be changed in the DB by a bad actor since it is just a field value. The Current User unique is accessible client side and a bad actor can modify the value in the DB client side, even with Privacy Rules, because most likely the privacy rules is ‘current user is this user’ and therefore they can access their fields and make changes to them.
If you want a real secure Privacy Rule around Admin roles, you need something like this…current user email is admin@app.com however, that is not possible as the email field is not accessible via Privacy Rule expressions, and I believe @georgecollier you mentioned our Privacy Rules are part of the App Code that is downloaded on page load, so they are visible for a bad actor to see.
Only in debug mode (which people can’t access unless they’re an editor on the app)
This isn’t quite right. You can only change fields through workflows, unless you have to permission to autobind a field, in which case you can change it directly. The exception to this is under a specific set of circumstances when you’re logged out and it Bubble doesn’t check correctly.
(in a previous post you were stating it was 0.02 WU - which would make more sense)…
UPDATE:
I just ran my own test of this…
Using the condition: Current User’s Role is Admin
For a WF with only client side actions, there were 0 WU consumed (as expected - as the condition for a client-side action would be evaluated on the client, where the User data has already been loaded)
For a WF with a server-side action 0.02 WUs were consumed - again, exactly as expected, as the condition is evaluated on the server for a server action, and therefore requires a Data request, plus some data, so 0.02 WU is about what you’d expect.
So this seems to be working, and costing, exactly as expected.
Thanks for pointing that out, just updated thread subject line.
That is the wrong condition to test. Need to test condition that forces server side evaluation, something like current user is logged in and current user role is admin.
What data? The current user data or the data of the thing to create/modify?
Update: Bubble support has now been able to look through my original steps and are able to reproduce the bug that I reported. That bug is if you use the condition current user is logged in and current user role is admin in order to force a server side evaluation (whether there are server side actions or not in the event series), the costs are inconsistent when running tests with actions that are server side, like create/make changes to thing versus when only client side actions are present.
What this means, is there is either a bug in the system (or maybe unpublished intended behaviors) where the ‘current user is logged in’ does not actual always force a server side evaluation, or the cost of 0.02 WUs for individual data request is being charged and should not be, or is not being charged when it should.
I think the takeaway here is that it’s pointless to have those conditions on your regular workflows because a client side action can be bypassed anyway.
Most of the time I use a backend workflow that the clientside workflow is just scheduling. The condition should sit on the backend workflow being triggered, with the condition for the client-side workflow itself remaining blank, because that can be bypassed anyway.
For any server-side actions that are client-side, like Make changes to a thing on a client-side workflow, just put the condition on that specific action. I think that covers security and WU in the best possible way.
It is what it is, but the cost of the conditional checks out