Ideally, I would want to define those variable as private, which is possible at the API call level.
Here, when I try to do the call, I can’t pass any parameter.
Am-I missing something ?
Is this possible at all ?
If not, how to you manage API variables endpoint and variable authentication depending on the Main/Live environment ?
Try changing the API’s authentication to self-handled and then configure whatever you need as a specific call, where you can include dynamic parameters in the path, headers, or body. Ensure you only ever invoke the API call from a backend workflow so that the confidential values are not loaded client-side. Once you have it working, delete the default values from the API Connector’s configuration since those are loaded to a user’s client device.
Hi David,
Thanks for your reply.
Just to be sure, are you suggesting:
1: to add a identification call in the API and then, somehow, reuse the token in other calls ?
2: to duplicate identification settings in each API call and not using any shared parameter at the API level ? (this would, If I get it require means that the Proxy should verify user/password at each call and not reuse a past generated token)
In any of both scenario, I have the feeling that we would loose the Oauth2 token benefit which has a validity and does not require authentication at each call. But I may have missed something.
As a reminder, I just need 2 users and passwords: one for Main and the other for Live. I don’t need each users to use their own credentials.
I use the approach that I outlined for an integration where different authentication credentials are required for different groups of my app’s users. Also, in my scenario the authentication protocol is Basic, not OAuth2.
If it’s not worthwhile to configure a dedicated call where you can use dynamic values, then AFAIK your only other option is to configure parallel APIs and invoke the pertinent one depending on the app’s version. I believe there’s no way to include dynamic values in shared headers.
@Jici is among the most helpful forum contributors regarding API matters, and may have better guidance.
Sadly, actually Bubble doesn’t allow dynamic part in most of the Bubble auth option. I have requested that while I was talking with @grace.hong almost a year ago. They added dynamic part on the auth urlin user-agent flow, but nothin else. I also ask Grace to add “dev” option to all call.
The only option you have actually is to set self-handled, create a call to get the token with the dynamic url part (if needed) and dynamic key/value settings depending if you are in live or not (Use isn’t live version:format as text to set the correct value for yes and no)
Hi @Jici
Thanks for your support.It’s indeed sad to see that even the option to have dev settings is not available for such usecases.
The option you outline would require my Bubble app to manage Token manually (self-handled with variable), reuse that token in all further calls and, then, do a new call to generate a new token when expired if I got it right. Exact ?
Also, I never played with custom plugins but do you think that this would be an option: building the dev-prod switch once for all in it, but still keeping the benefit of the OAuth2 managed by Bubble ?
Can the plugin actions reuse the API definitions ? Or would it be required to re-build the OAuth2 connexion in Javascript as an action ?
You don’t need to care about refresh token with client_credentials. Just fetch for a new token each time. Juste created one call that you use as DATA to fetch the token. Put this request in API Call after in Authorization header of each call.
Thanks, understood. I’ll give it a try.
An alternative we came up with my team is to modify our Token route to accept both Live an Main configurations for clent_id and secret_id (thus, also configuring client_id_dev and secret_id_dev in the API connector).
The token engine would then use one or the other depending if the requestor contains “version-test” or not. It’s not super clean but it might work and requires less steps and conditions on the Bubble side.
Thanks
Unfortunately, I have some bad news regarding our recent updates.
The plan to use the same token route for both Main and Live environments does not work. Bubble shares the same OAuth2 token across both environments. This means that even though the token route receives information to distinguish between Main (app_version=test) and Live (app_version=live) in the call “baggage,” it is ineffective. Once a token is fetched by any environment, it remains valid and shared across both, regardless of the originating environment.
This situation is concerning because Main and Live share the same accesses. It may also explain why the Bubble team is hesitant to support Jici’s proposal for a unified development configuration for all calls.
As an alternative, we decided to duplicate API calls in the API connector, creating separate APIs for Main and Live. This approach involves duplicating all calls in the workflow, each conditioned on the environment. While more labor-intensive, it seemed practical. However, this solution also failed : Bubble perceives the outcomes of both APIs as different object structures, even if they are identical.
To proceed with this approach, I would need to duplicate objects on the page, essentially duplicating the entire page. This is impractical as it would require excessive work and introduce too many risks of errors.
We’re also reluctant to use Jici’s proposal to get a Token for each call as this would mean loosing the benefit of the OAth2 token standard which reuse the token until it expires. Getting a Token for each call would create overhead with impact on costs and performances.
Thus, I am back to square one, unsure how to manage this issue. We will explore the plugin route to see if it offers a better solution.
I don’t think this is the problem because probably that the token endpoint is just returning the same token each time. This happen often in client_credentials until you use the refresh token or until the token expires (if the token expires). I even don’t think Bubble store the token at all. It’s not like the oAuth user-agent flow.
The solution to duplicate eveything will work, but will lead to a lot more maintenance work. Again, the best is just to use dynamically the client_credentials request instead of letting Bubble do the token request.
And yes, each API call create their own “Type”. Even if the result is the same. There’s no way to tell Bubble to use them as the same type (sadly).
So if your process to get the token with a different “version” parameters in the body work, I don’t see any reason to use a different route. Don’t care about the token is the same for live and dev. It doesn’t matter.
In fact, from what we experienced today in our tests, the token endpoint does not receive a call for each environment.
It receives one call (from Main or Live, depending on which one runs the call first) and Bubble seems to reuse the same token in both Main and Live environment.
If everything means everything, yes it would work and yes it would generate a massive amount of maintenance work.
If at least Bubble could share objects between APIs when the structure is the same, that would reduce the amount of duplication work required.
As we experienced, 2 different APIs (event exactly the same) return 2 different data type objects that are not compatible. Bubble cannot “display” the result of both APIs in the same object.
in the actions, trying to make a different call for Main and Live → got the issue that the object types of the 2 different APIs are not compatible (thus, requiring to duplicate “everything”, which is a no go)
trying to modify our “Proxy” Token route to switch between Main and Live → we first started verifying that the Token route was receiving the relevant information to make the switch → got the issue that Bubble share the same token for both environments.
Here are the settings for our Token route :
It is not possible to change any of the Authentication settings dynamically from an action or from a data call : even if API connectors allows to specify in the Body and identify them as variable bellow the Body input, it is still impossible to modify them from elsewhere than the API connector.
This is exactly what we told you. There’s no way to set this in the Auth part. You need to set this in the Call part.
So if you want to set proxy_env, set it at the call level, not at the auth level.
OR like we also suggest, remove the auth, set selfhandled, create a Call that get the token and set header to all other call for auth. When you call an API call, set the authroization header with this first “Token” call
@Jici@davidb
Unless mistake on my side, what you suggest will work but is a massive loss of ressources.
For each API call, your suggestion is (again, if I’m not wrong):
move all API calls in backend API workflows (to protect client_id, secret_id and the token from being cought front-end).
then, for each API call
add a step with a call to the token route to get a new single-use token → there, I could either get a dev Token for Main or a prod Token for Live
re-use once the generated single-use token in the API call as a variable in the API call to get data or do an action, where I could specify which environment I target (dev or prod)
This will work, indeed, but
it’s technically (environmentally & economically) a nonsense to throw away the token after each usage since OAuth2 security has the objective to reuse the Token for all users of an entire application until it expires. All of this should be transparent. All of this is properly managed by Bubble today … appart from the fact that Bubble is re-using the same Token for Main and Live preventing any workaround.
it’s also becoming overly complex to build the app: instead for doing “simple” front-end “display data in an object”, I need to manage backend workflow with data in-out for each API call + duplicating all API calls with the get-single-use-token step.
Is my understanding of your proposal correct ?
If yes, there must be a way to manage this properly with the benefit of the OAuth2 mechanisms and Main/Live environments.
I thank you for your help and I understand that your advices is to get this working with the current level of Bubble features.
On my side, I raised a ticket to the support. I hope that they can suggest a better approach or change something so that we can use 2 different environments outside Bubble as well.
The last solution I was reluctant to investigate is the plugin thing.
If I misunderstood your proposal, let me know.
On my side, I’ll update this post as soon as I make progress.
