Seeking Advice on User Token Management in Bubble

[travis.polland]

Hi,

I’m working on an application that requires user token management, and I’m facing some challenges. I’d appreciate your insights and recommendations.

Current Setup

I’ve designed a workflow that includes:

1. User sign-in process
2. Backend workflow for generating an API token
3. Frontend and backend workflows that need to use this token

Main Challenges

1. Token Capture: I’m unsure how to capture the user token generated by the backend workflow.
2. Token Storage: I need advice on the best method to store this token for reuse.
3. Token Accessibility: I’m looking for efficient ways to access this stored token in various parts of my application (both frontend and backend workflows).
4. API Integration: I need guidance on how to include this token in API calls from different workflows.

Specific Questions

1. What’s the most effective way to capture a user token generated in a backend workflow?
2. Where should I store the token for easy access across the application? (Custom state, hidden input, or other options?)
3. How can I retrieve the stored token when needed in different workflows?
4. Is generating the token immediately after user login the best approach?
5. Are there any security considerations I should be aware of when implementing this token system?
6. Do I need to handle token expiration and refreshing? If so, how?
7. Are there any built-in Bubble features or plugins that could simplify this token management process?

Desired Outcome

I’m aiming for a solution that:

• Allows easy capture of the token after backend generation
• Provides straightforward access to the token across all workflows
• Maintains security best practices
• Integrates smoothly with API calls

I’ve created a diagram illustrating my current workflow, which I believe might be missing some crucial steps.

Any code examples, workflow suggestions, or best practices would be extremely helpful. Thank you in advance for your assistance.

[animisha45]

A couple of things:

1. Log the user in does not work in the backend. So this should be an action on the respective page.
2. If you are talking about token generation for user login, then you do not need to set all this up. Bubble takes cares of it for you. You just have the log the user in and check if user is logged in in conditions (where necessary)

If you are looking at token creation for other reason, could you mention it? You would get more accurate response.

Hope this helps!

[travis.polland]

Thanks for your response! I appreciate you taking the time to help, but I think I might not have explained my situation clearly enough. Let me give it another shot:

You’re absolutely right that I don’t need to set up token generation for Bubble’s built-in login - that’s not what I’m after here. My situation is a bit more complex, and I’d love your thoughts on it.

Here’s the deal: I’ve got these LangChain Agents running in the Microsoft Azure cloud. They’re pretty cool, but they need to talk to my Bubble app to get some extra context as they do their thing. Specifically, they need to use Bubble’s Data API to fetch user-specific information.

Now, here’s where it gets tricky:

1. I’m using Bubble’s API Connector to set up the communication with these LangChain Agents.
2. When I make a call to a LangChain agent (which happens in various parts of my Bubble app), I need to pass along the user’s token so the agent can turn around and use that to access the Bubble Data API.
3. This isn’t just a one-time thing - I’ve got multiple LangChain agents, and I need to make calls to them from different frontend and backend workflows all over my Bubble app.

So, my big question is: How do I consistently get hold of the current user’s token and pass it along in these API calls? I’m scratching my head over a few things:

• Is there a way to grab the user token after login and keep it handy throughout their session?
• How can I access this token easily in both frontend and backend workflows?
• When I’m setting up these API Connector calls, what’s the best way to include the user token as a variable?

I’m really hoping to find a way to manage this token business that’s efficient and doesn’t involve me copy-pasting the same logic all over my app. Any ideas on how to set this up smoothly?

I’d be super grateful for any thoughts, examples, or even just a point in the right direction. Thanks again for your help!

[animisha45]

@travis.polland

How do I consistently get hold of the current user’s token and pass it along in these API calls? I’m scratching my head over a few things:

You can do two things, either

• use Current Users unique Id.
  or
• (I would recommend this more) You can create a custom data type with fields such as token, user, expiry date, etc. Create a token using random strong generator. You will have to create proper workflows to ensure you only use the latest token at any time.

I think this will also answer the other questions you have. Creating new data type will allow you to have better control throughout.

[eliot1]

You should try the following:

1. Create a DataType “Token” with the following fields: tokenType (string), expireDate (datetime), tokenAccess (string), User (user), clientID, clientSecret. Create a field in user: Token (token).

2. Create a backend workflow to generate, capture and store the token.

• Store it in the Token table using the data from “Result of Step [API step]'s token”. Make sure your API send back the token as a result.
• Do not store it in a Custom State because you might need it through multiple pages within your app during the same session.
• Add a condition to this backend workflow to generate a token only if the user’s token expireDate is smaller or equal to Current Date Time (date in the past).

3. Anytime you need the token, call the backend workflow of generation first, then your API call. Just grab the AccessToken in user’s Token Access Token. Make sure you unchecked “Private” in the API connector next to the token variable.

4. About the token generation. Do you absolutely need the bubble user’s password? Because it sounds not very secure to share it this way… Can you give more information about the API call to generate a token? Maybe using ClientId and ClientSecret in backend workflows is a little bit more secure.

Hope this help.

[travis.polland]

Hi,

I don’t want to use the Bubble global admin API key for the application as per Bubble documentation; it is best to use the User Token (documentation).

I followed the documentation linked above to obtain the User Token per its instructions, which should return the token. It says that I would need to log the user in. I don’t want to ask the user to log in each time I run a workflow to the API, which needs the user’s token.

[travis.polland]

Okay, I think I got it based on both @animisha45 and @ed19’suggestions. First, the lesson learned is that calling the backend workflow for this from within the frontend workflow doesn’t return a token (or JSON response). I had to expose the backend workflow API for external calling. Then, I configured a Bubble API Endpoint in the API Connector. I can then call this from the workflow, which will return the full JSON. (additional forum stuff).

I know I have the full JSON response and can pass the credentials in the workflow… with constraints as you suggested.

{
    "status": "success",
    "response": {
        "token": "bus|1721xxxxxxxxx589010xxxxxxxxxxxx|172xxxxxxxxx4x32xxxxxxxxxx602xxx",
        "user_id": "1721728852224xxxxxxxxxxxxxxxxxxxx",
        "expires": 31536000
    }
}

My final question is: What is the expiration format returned in the JSON payload, and how do I store it correctly in the Bubble dataType field?

[zelus_pudding]

@travis.polland , yes, as you’ve surmised, 31536000 is the number of seconds it will take this token to expire.

[travis.polland]

Thank you @zelus_pudding

[travis.polland]

Here was the solution

• new dataType for the Token (fields defined from previous thread)
• Expose the backend workflow to the internet and secure it behind authentication
• Generated a private global API key for internal usage (Settings)
• Configured this endpoint in the Bubble API Connector
• Added a step in the sign-in workflow to execute the the API and passing in the user’s credentials (email and password)
• Added another step to create a new thing in the Token dataType for the user
• Added another step to update an existing thing if isthe token where to expire
• Managed the Only When conditions on the API call, new thing, update thing based on the existence or expiration of the thing (min WU calls)

[animisha45]

Awesome!

[travis.polland]

Just a follow-up best practice question.

In effort to use the least number of WU, what would be the best condition for the actions in the workflow?

Sign-in Workflow

Get the User Token via the API
Only when: Does a search with a “or” have a huge WU cost?

Save a new thing in the Token dataType
Only when: Does a search with a “or” have a huge WU cost?

Update an existing thing (token)
Only when: Does a search with a “or” have a huge WU cost?

[animisha45]

@travis.polland

least number of WU,

All the conditionals are about count. So, have a look at this:

Brenton 🫧

They explain which consumes the least WU in case of count.