I’m using an API that requires OAuth2 authentication. It works fine. However, some data for the token generation should change from development version to production version. More specifically, the URL and one header in the request to get the token must be different in development and production environments, but I haven’t found a way to change them dynamically or anything like that.
Is there some kind of workaround? It is way to impractical to change them manually at each deployment.
Thanks in advance
Use the “isn’t live version” which evaluates to a yes/no and then use the “:formatted as text” and then in formatting for yes, put the info for your dev version and then in formatting for no, put the info for your live version
edit: I had replied the wrong answer
edit 2: small error correction
So I actually didn’t know what you meant with “identity provider” in this context, but from a simple search I think you mean the endpoint / url where I get the authentication, is it right?
That works for the normal endpoints/url, but the native Bubble OAuth2 does not support variables in the Token url and headers. I can change them in the finals urls where I’ll get information, but not in the token url that I access to get the authorization temporary token.
I actually have two workarounds, but they are a little complicated and prone problems in future modifications.
Workaround 1: Make a manual system to handle the OAuth2 token refresh. Just a variable with the valid token and a scheduled backend workflow that refresh it or just check and refresh if required every time I need to use. With so, I can make have one token for dev and one for prod and use each one accordingly. It is rather annoying to insert the token every time and not use the native OAuth2 system, but maybe not horrible.
workaround 2: Make two different API groups, one for dev and one for prod and in the workflow put them both with “Only when …” conditions accordingly. It is more prone to forget it in the future and it probably will be annoying to treat both responses the same way.
Faced the same limitation and couldn’t find a better workaround (I went with option 2)
Probably too much of a low hanging fruit for the Bubble team to have missed it, so I’m wondering what’s the actual reason for not allowing variables in there
I personally started handling it manually (workaround 1). I saved the token as a variable (with its value, expire date and a condition if it is prod or dev) in the database and created a custom WF that checks the token, so I call it before every API action.
The WF is the following : delete all old tokens; stop if there is a valid token; get a new token; create a new token object in the database.
Then, when making API requests, I used variable fields (the [] and <> in the request) with the function “Isn’t live version”.
It takes more work to implement, but if you have a large number of API requests, it is basically just copy and paste, so it’s not impossible.
I’m facing the same issue of having to handle dev and prod for a set of similar calls (different Token endpoints, different parameters), and haven’t found anyone else talking about this on the forum
It’s interesting that you each went with a different workaround @vicente1@Lucien
I wanted to ask you if you had found a better solution since then or if, in hindsight, you were happy with the option you picked.
