How To Assign A User To A API Workflow Endpoint

[JustinC]

I have a webhook that triggers a workflow by API (with authentication) but it doesn’t run as a user.

How do I assign it to a user so that it runs as a user in the ‘created by’ sections and actions the workflow undertakes?

[keith]

Authentication:

Introduction

• Session cookie. If the call is done from the browser and there is a session cookies present, the user represented by the cookie will be the call will be run in the context of this user.

Obviously, there are some typos here, but you should get the idea? If I’m logged in to your app and I call your app’s workflow API, that workflow runs in my context.

If I am not logged into your app, this API will fail as I am not authenticated – unless authentication is not required, in which case it will run.

NOW, this isn’t a very common sort of use case, if you ask me. The more common use case is: I have integrated to some external API. That service (whatever it is) has a webhook facility that can ping me when something happens over there.

(e.g., that service has users who might also use my app. They have given my app permission to do stuff. The external app has webhooks. Those webhooks can ping my app to inform me about some change over there and it only pings MY endpoints for changes that happen with respect to users who have authenticated my app.

I don’t want just anybody pinging those endpoints. So they require authentication. That authentication should be in the form of a token. I make a token in Settings. I use that token to configure the webhooks over in the external app. This token represents THAT OTHER APP and is not shared with anybody else.

If it’s just a basic webhook, you’ll have to do as the reference says here:

You can also add your API Token directly in the URL for both the Workflow and the Data API as a querystring parameter api_token . This approach is not recommended as it is less secure. [than the part I’m going to quote below…]

If you’re granting somebody permission to integrate to your API and they are developing stuff, you’d do it like this:

– Use an API Token generated in the API section in the Settings Tab. This API Token is secret and should not be shared with anyone. To authenticate with such a mechanism, add Authorization: Bearer API_TOKEN to the header. When you authenticate with such an API Token, the call is run in the context of an admin user of the app, who has access to all data.

[keith]

CORRECTION: SEE:

– Create Sign up/Login API workflows. This is useful for building an alternative front-end to the Bubble app, such as a native app that you developed. When an API workflow contains a sign up or login action, then a user ID, token, and expiration, expressed in seconds, are returned with the response of the call. Subsequent calls to the app’s API, with a header Authorization: Bearer API_TOKEN , runs all calls and workflows in the context of the user associated with the token. This user will be the ‘Current user,’ who you can access with actions. Privacy rules will apply to this user as they would if the user was logging in the Bubble app and using it in their own browser. This token should be kept safe.

SO… apparently you can build an API workflow “login” or whatever you want to call it. With this you return a token to the caller. The caller can then execute other API workflows using that token in the Auth header, until the token expires. Once expired, the caller will have to hit the “login” endpoint again to get a new token.

I suppose this is sort of OAuth 1 style. (I guess?) In OAuth 2 style, this would be more complex and we’d do a handshake to exchange a code for an initial auth token and refresh token. That token would be valid until it expires. Once expired, the caller would hit our “refresh token” endpoint and exchange the refresh token for an unexpired auth token (having been used, the refresh token is now expired) and the cycle repeats…

But our Bubble apps are not Oauth 2 style yet.

[keith]

… SO, part 2:… I guess one thing you CAN do is to make your “login” endpoint such that it takes username and password in a querystring and then uses those to log the caller in as the user associated with those credentials. That endpoint will respond with the token as per above.

I wonder if this means that you can make an endpoint (called “do something in context of user”) that takes username and pass in the querystring and then:

Step 1: does “log in/sign up”
Step 2: does the value returned in step 1 return a token into the workflow? If so, I guess you could…
Step 3: Call another API workflow using that token

In this way you would “wrap” API endpoints that require authentication with a login action.

I guess one would have to try that out. I’ve not tried it out. I might try that out.

[keith]

AAAND further, @JustinC, “oh shit that works!” Here’s an example:

Let’s say you want to make one of your POST endpoints (“workflow endpoints” as Bubble calls them) available, but only via a username and password. Further, let’s say you’re OK with allowing the user to put their credentials in the querystring.

Let’s create an endpoint that will return the user’s first name. Create your endpoint like this:

Querystring params email and pass are the user’s email address and password, right? (Duh, I know.)

Here’s our workflow:

Call your endpoint. As you know, this endpoint in dev mode will be:

https://your-app-base-url.com/version-test/api/1.1/wf/return-my-first-name?email=useremail@example.com&pass=userpassword

Let’s call it from Postman with a email and password pair that are valid: In this case, the user’s first name is “Lodgable”… We see:

Now let’s call it without any arguments:

OK, that’s cool. (Though I suppose I could do without Bubble telling you OH HAI, THIS MUST BE SOME LOGINABLE SHIT RIGHT HERE, PUT IN AN EMAIL!!!)

And so now we try it with an invalid email and pass:

Well, we don’t run the workflow. So that’s cool. But GEEZUS Bubble, could you make it any easier to invite a brute-force attack? (I dunno… is this what REST APIs are supposed to do? This one seems a little overly friendly if you ask me.)

And so now we try with a known email, but give the wrong pass:

Well, thanks again, Bubble. But hey, at least our workflow does not run.

Obviously, it’s better to have these things in the POST body and not expose them as querystrings. But that’s how you can make that work, @JustinC.

NOW, I know what you’re saying about the above example. You are saying:

“Well, that looks a lot more like a GET request than a POST. How can I do this as a GET?”

The answer is that you can’t without some shenanigans. The GET side of the Bubble API is reserved for the dorky built-in DATA API. (Frankly, I think this sucks.)

However, if you DID want to expose this POST and make it accessible as a GET, you can put Amazon API Gateway in front of your API. It can do little tricks like turn a GET into a POST. I’ve shown how to do that elsewhere in the Forums. To find a screenshot of that, you could search @keith AAPIG and it should turn up.

[keith]

BTW: Do not try to hit my example endpoint. It was created just for the purposes of this reply. It no longer exists and you can no longer hit that endpoint.

[JustinC]

Thanks for all of this it’s well appreciated Keith.

I guess I’ll have to have a login/signup action in order to have a ‘created by’ field as right now in the logs it looks as an " anonymous user " is completing actions based on the authenticated API endpoint.

[keith]

It seems that way. Keep in mind that apparently if the flow is just a login action, it ‘s supposed to return an auth token. (I’ve not tested that as yet.)