Run As User Action for Backend Workflows

boston85719 · 2024-12-31T05:03:53.320Z

In the app editor there is a feature for run as…it allows us to login as the user and run the application as that user without needing the user password. This is possible because from the app editor, it assumed the user accessing the feature is the app admin.

For securing backend workflows we can use Admin API Tokens. When a backend workflow is triggered via API call that contains the proper Admin Tokens, the actions run as if the user is the App Admin. This allows for any actions to run and always ignores privacy rules and makes it so that any data created is created by ‘app admin’.

There is a way to run backend workflows via API with a User authentication, but that requires the user email and password be sent via the API call and running an action to log the user in. This makes it difficult to implement as the app developer we do not have access to the Users password.

There should be an action to ‘run as user’ in the backend workflows that can only be run if the server is running as app admin (like via a Admin API token) and only requires the users unique ID or email address. This way we can have the ability to run the backend workflow as the user designated through the ‘run as user’ action and all privacy rules will be followed according to that user, and all data created will be created by that user. This will eliminate the need to pass through the API call the email and Password, and make it much more flexible for developers in how they utilize backend workflows initiated via API calls.

The idea came up because of this thread…

boston85719 · 2024-12-31T05:49:58.799Z

This is specific to the idea of using a backend workflow as a webhook, so if a API call is received, we can configure that to have a user unique ID value passed in, whether as a parameter or in a similar way as an Admin API Token would be…having the user unique ID as another parameter or similar to Admin API Token would just provide the ability to run as the user without needing email and password to be sent through.

The fact that backend workflows often have more parameters than just user doesn’t in any way affect the usefulness of the feature or alter the practicality…unless I’m missing something from your point, which I summarize as ‘because there are often many more parameters than just user, it is not practical to be able to run the workflow as a user’.

mitchbaylis · 2024-12-31T05:51:29.140Z

just uncheck the “expose api” and it is secure enough

for exposed apis you could create a token and add a condition to check that the token is correct before running the workflow - I’d do this in a custom event to make it easy to change the token, or I’d store the token in a data somewhere and then set privacy rules on it.

you could set different tokens for different access I guess if you really needed to restrict access.

boston85719 · 2024-12-31T06:10:43.099Z

mitchbaylis:

just uncheck the “expose api” and it is secure enough

The idea is for webhooks…if you do not expose the api, webhooks can not run

mitchbaylis:

for exposed apis you could create a token and add a condition to check that the token is correct before running the workflow

I think you missed the point, this will run the actions as app admin and will ignore privacy rules and create the data as app admin…whole point of the idea is to make it so that doesn’t happen

mitchbaylis:

I’d store the token in a data somewhere and then set privacy rules on it.

This does what?

mitchbaylis:

you could set different tokens for different access I guess if you really needed to restrict access

And each token is an API Admin Token that will run the actions as the App Admin…again, missing the point of the idea.

Read the thread the idea came from so you might be able to track the reason for the idea.

mitchbaylis · 2024-12-31T06:39:45.116Z

you could use the tokens as filters to not create/edit certain datas

if api is triggered with token A - then access everything, if it is triggered with token B then only access contacts and not companies (using conditional filters in the workflow)

this achieves what you want using the existing bubble architecture.

I suggest storing the token somewhere so the user (admin user) can change it or set it so that they can create their own tokens to share with 3rd parties

ie you could create a data “token” - set strict privacy rules on it for security
then allow users to create tokens
system generates a random 15 character string
allow users to add “permissions” to the token via an option set

then in the backend workflow you can add conditions where you lookup the token to see the permissions and then run or not run certain events

my original idea was just tokens but you can extend it with option sets and add more functionality for users to self manage their tokens.

allowing users to reset tokens also creates better security as when they remove a token then the workflow conditions won’t run anything - giving them the ability to control their own access

I don’t see the need to have users on api workflows as you can do what you want to do using existing bubble logic quite easily.

I read and understood your post and you can achieve what you want using the logic I shared. I do not think adding oauth2 style access constraints to the backend workflows is needed

if you really wanted it you could already achieve it anyway
add a list of permissions to the users
generate a token per user (allow them to refresh it or even disable it)
do the same method above but this time lookup the users, get their access and then use it to control the apis access

boston85719 · 2024-12-31T07:42:16.862Z

mitchbaylis:

if api is triggered with token A - then access everything, if it is triggered with token B then only access contacts and not companies (using conditional filters in the workflow)

this achieves what you want using the existing bubble architecture.

No it doesn’t as it doesn’t create the data as the user in the created by built in field, it creates it as the App Admin…one of the key points in the idea suggested.

It also adds an enormous amount of unnecessary complexity.

mitchbaylis:

I suggest storing the token somewhere so the user (admin user) can change it or set it so that they can create their own tokens to share with 3rd parties

Thanks for the suggestion, that is already part of Bubble. You can find this in the Settings tab, under API tab

Screen Shot 2024-12-31 at 2.36.48 PM677×197 9.93 KB

mitchbaylis:

then allow users to create tokens

Not possible

mitchbaylis:

allowing users to reset tokens also creates better security as when they remove a token then the workflow conditions won’t run anything - giving them the ability to control their own access

I think you are saying instead of using the secure API Tokens generated in app editor under API tab, to create our own less secure tokens…this misses the point of still using the secure Admin API Tokens for authenticating the workflow via API call that is a webhook event notification, since it is important to ensure the API is not called from a bad actor.

mitchbaylis:

I don’t see the need to have users on api workflows as you can do what you want to do using existing bubble logic quite easily.

To have privacy rules enforced and have created by field filled in as the user and not app admin…I suppose you still are missing the point of the idea

mitchbaylis:

do the same method above but this time lookup the users, get their access and then use it to control the apis access

Sure, but this costs WUs to lookup the User, and is not possible to sign them in so that the Privacy Rules are enforced or that the data created has the created by field as the user and not App Admin

mitchbaylis · 2024-12-31T08:21:07.056Z

no real difference between a bubble token from the settings page and a token you generate for a user - it’s just a string of characters that acts as a password to authenticate a request. as long as that string is protected with privacy rules you get the same outcome and security - but yes, there are wu costs involved.

3 ways to run bubble api workflows

run with bubble token (built in method but restricts to 1 auth per bubble app)
run with custom token / separate tokens per user in the methods I shared (allows 1 auth per user/token)
run with no token (public)

should bubble add oauth/impersonation to backend workflows? maybe, but I doubt they will anytime soon and I don’t see a need for it.

if you want to log the user then just add a field for it - yes, not ideal and not a “system field” but it works just fine.

boston85719 · 2024-12-31T09:20:13.717Z

mitchbaylis:

run with bubble token (built in method but restricts to 1 auth per bubble app)

Not correct, can have multiple…if you have not explored this check it out, you can create multiple tokens

mitchbaylis:

should bubble add oauth/impersonation to backend workflows? maybe, but I doubt they will anytime soon and I don’t see a need for it.

My idea is to add a ‘run as user’ action that accepts the users unique id only. The need for it if that is still not clear for you is so that the privacy rules will be enforced as per the user and the created data will have the field of created by filled as the user…this is so that we do not need to send in the email and password.

If you have not explored how this functions check out the manual link I posted in the linked thread the idea came from and you should then have some better understanding of the need for it, or at least the reason for the want.

mitchbaylis:

if you want to log the user then just add a field for it - yes, not ideal and not a “system field” but it works just fine.

You can not log a user in without their email and password…basically the point of the idea.

mitchbaylis · 2024-12-31T09:45:12.042Z

I’m not sure what the issue is then - you can already do oauth with bubble re the doc you mentioned?

manual.bubble.io

As a User | Bubble Docs

This section covers how to authenticate an API client as a user logged in to your application, allowing you to protect your data with Privacy Rules

I’ve never needed to use that auth method but it’s good to know it is there - thanks.

as per the documentation privacy rules and created/modified user are enforced after authenticating the api call with the oauth method. I haven’t tested this but the docs say it is already possible.

it would be a big security flaw in the backend workflows to be able to authenticate as a user by simply sending in the users email or id - I do not see a need to do this and it would be an easy security flaw to take advantage of.

and yes - you can have multiple admin tokens in bubble, but that’s different to what I was talking about where I give users the ability to manage their own tokens and those tokens access

the admin tokens give access to all backend workflows but user level tokens I can filter to certain workflows and also manage on a per user basis rather than a per app basis.

boston85719 · 2024-12-31T13:48:59.292Z

mitchbaylis:

I’m not sure what the issue is then

I have gathered as much

mitchbaylis:

you can already do oauth with bubble re the doc you mentioned?

Yes you can already do authentication

mitchbaylis:

as per the documentation privacy rules and created/modified user are enforced after authenticating the api call with the oauth method. I haven’t tested this but the docs say it is already possible.

Yes, this is true, and I believe from reading the documentation, you will have uncovered that in order to authenticate as a user, you need the email and password.

Screen Shot 2024-12-31 at 8.27.16 PM951×553 41.1 KB

mitchbaylis:

it would be a big security flaw in the backend workflows to be able to authenticate as a user by simply sending in the users email or id - I do not see a need to do this and it would be an easy security flaw to take advantage of.

It would not.

In order to authenticate an API call we can do as App Admin by sending in the APP ADMIN API Token, or as a User by sending in email and password.

When we are authenticated as an App Admin by the use of the App Admin API Token, we have secured the API call. When this happens, because the App Admin is authenticated, Bubble allows the actions to run ignoring privacy rules and creating the data with the created by field being App Admin.

When we are in our app editor, we are basically authenticated as the App Admin. We when in the app editor can create data, and if we do the created by is filled in as App Admin. When we are in our app editor, we can do a run as Action to login as a user without their password.

So there is no material difference in terms of security between using the app editor to run as user and login as a user without their password, or authenticating an API call as the App Admin and having an action to run that would be akin to run as user.

We can also send a magic link in an email that creates a login token of sorts that provides a function to send a URL that allows a user to login as a specific user without the password, or even entering the email address or unique ID of that specific user. This functionality is possible because when running server side actions like this, the server is secure and the user would be authenticated as the App Admin, in the same way as if they were in the app editor itself, or if they were authenticated as App Admin via an API call using the App Admin API Token.

If we can do the magic link feature and the run as feature securely, it is 100% without a doubt possible to add a run as user action in a backend workflow that would only be possible to run if the API call is authenticated as the App Admin using the App Admin API Token.

In terms of you not seeing a need for that, I can understand that, not everybody would, which is why I linked the post that gave me the idea that it is a useful and needed function to be added, as at least 1 user has an immediate use case for it, and I’m sure lots of other developers have some in mind (I do) and others may 2-4 years from now, have some that they could come up with.

mitchbaylis:

and yes - you can have multiple admin tokens in bubble, but that’s different to what I was talking about where I give users the ability to manage their own tokens and those tokens access

Yes, but in order for your approach to do what I am talking about (ie: sign the user in through backend workflow and allow the created data be created by that user) you still need to in the backend workflow run the log the user in action, which as per the documentation still requires the email and password of the user. With your approach, we would need to save to the database the user password. And yes, I know, you can have privacy rules, but there is a reason why Bubble doesn’t do that already and in fact, password is the only piece of data not ever made available to the developer, unless the developer fails to follow best practices and decides to save the password to the database.

And yes, as you pointed out, a flaw in your approach would add to the WUs involved since a search is needed to be performed.

mitchbaylis:

the admin tokens give access to all backend workflows but user level tokens I can filter to certain workflows and also manage on a per user basis rather than a per app basis.

Absolutely correct. But something I think you are not understanding, is that with the ability to have a user authenticated on backend workflows we can manage everything as we would everywhere else, as in utilizing the privacy rules to help manage things on a per user basis.

So, your suggestions, although fine, they do cost more money to operate, take more time to implement and open up potential security flaws. Now, I understand ultimately what I believe the point you are trying to make here, which is, we can already do something similar, so no need for a new idea, which, yes, for some people that may be a fine approach to commenting on the idea post as they may not have seen a way that is essentially the same as their idea already being available to them.

For me though, I’m fully aware of all the possibilities you have been suggesting. My idea comes from a pretty deep understanding of how Bubble operates and I see a potential new feature as a way to not only add the to the flexibility of the platform, but also to reduce our costs in operating the function.

But, I thank you for taking the time to highlight the existing ways we can achieve a somewhat similar function of logging the user in via backend workflow and creating data as that user in backend workflow triggered via API.