Bubble users' access tokens for Bubble API

thecliff · 2024-10-21T17:37:21.514Z

Hi,

I have 3 categories of users in our web app.
#1- Signed with login / pwd
#2- Signed with Google credentials
#3- Signed with Microsoft credentials

I wish to create things on behalf of 3 categories of users using Bubble API.

For Users #1, I’m easily retrieving their Access tokens with login / pwd API call.
For Users #2 & #3, I’m not able to retrieve their Access tokens with that same method. What’s the way to create things on behalf of those 2 categories of users when using Bubble API ?

Thank you for your help

javier6 · 2024-10-21T19:05:24.050Z

You can assign a temporary password to the user and continue your flow as normal.

“Assign a temp password to a user” → Current User
Create a backend workflow that you can call which “Logs the user in” using an email and password
Create an API call in your API Connector which calls this endpoint
Call this new API call you created, using the credentials generated in step 1. The result of this will be a token that you can reuse.

thecliff · 2024-10-21T21:38:05.924Z

Sounds great. Didn’t know “temp password” can be used like this.
The flow is pretty clear, thank you for this quick answer.

I would like to store some data in cookies so I can retrieve the user’s access token more easily when he will be using our chrome extension.
What’s the best practice to store the token in user’s cookies ?

javier6 · 2024-10-23T13:11:10.188Z

I’m not sure I don’t do too much related to the user cookies, you could try using Floppy to store data in localstorage which is persistent.

I wouldn’t recommend storing sensitive information like the token in the browser without encrypting it however. If you are loading bubble via an iframe through a browser level plugin, the plugin should have permissions to store cookies, meaning if the user signs in via the iframe, it will store the bubble login cookie by default.

If you really need to store it in the browser, you can encrypt the token server side and salt it with a unix timestamp of when it expires, then store it in the user’s browser so that when you retrieve it, you can check if it’s still valid first and reissue it if necessary. By default, it has a 1 year expiration, so I’d probably generate the token and encrypt it as

[token]|[current date and time + 1 year]

This way when you retrieve it you can just have the unencrypted token split by “|” and item 1 will be the token itself, and item 2 will be the expiration date of the token.