I’m having trouble configuring this option. If this option is not checked, the API works normally, but when I activate the API, it stops working. The API has no header or parameter specified. Could anyone help?
@gerry98 any news if Bubble will extend this functionality to allow API calls with headers to be made from the browser?
My use case: I’m trying to integrate Supabase with Bubble app in GDPR-compliant way. In this case, need to get my data from Supabase directly client - Supabase server (without running the call through Bubble in the middle).
But in order to access the data, I need to pass the Authorization Bearer token together with the request (token is user-specific, user authorized with Supabase before).
Hey @emmanuel@josh@gerry98, is this feature still in the pipeline? Can you please make it available in today’s pricing scenario? It would be really helpful in minimizing our workload.
Still no improvement in doing an api call from the browser?
I always get “expected a 2XX statusCode but got 0” when flagged, I tried to recreate the call but no luck.
For anyone experiencing the “expected a 2XX statusCode but got 0” error, the solution found by @Jici is to ensure the API you’re using allows CORS requests.
If I have a backend API flow that uses a user’s API key (secured with data privacy rules) to query external data, and I call my own backend endpoint directly from the browser (providing only the user identifier), is there any risk for the user?
To clarify, the browser makes a call to my backend, which then uses the user’s API key (stored securely on the server) to perform a third-party API call. The response sent back to the browser does not include the user’s API key.
Is this approach secure, or are there any potential risks I should be aware of?
You added a second level of security doing this. If the API key that belong to the logged in user, there’s no need to call the API using backend WF, but this add another level of security. (but cost more WU and slow down thing). The main thing is to set privacy rule so only current user can access to is own key.
The backend WF step is only needed if the user access to another user API data. At this moment, you need to keep the API key for the other user secure.
Finally, don’t forget to set your backend WF to no be available as a public endpoint.
@Jici, i understand what you’re saying, but I can’t figure out how to get around this. See, I use a bank’s API to perform financial transactions like Stripe. I can’t set the call with the API key to private because it needs to be dynamic. Every user with a business account has this API key. Up until now, I was making simple calls (like returning the account balance) directly from the frontend, but this was exposing the user’s key to the browser, even though only the user could see it.
My solution was to make this call in the backend and access it via the API Connector, so the key is hidden from everyone, even the user who owns it. As for leaving the WF backend as a non-public endpoint, that way I wouldn’t be able to access it directly via the API Connector, right?
Each account is created under the root account, meaning each user with a business account gets an API key for their own account. My concern is not necessarily that he will see the key, but that malware in browser extensions, for example. Shouldn’t I be worried about that?
Maybe I can use the schedule workflow for some cases, except when I need immediate feedback. Thanks, I’ll take a look.
No… and Yes… From my point of view no: it is the user’s responsibility to be careful about what they install. Yes… a third party tool could catch this (but it’s not that simple and this need to be disclosed in extension manifest for example. If the user navigate to a page, a JS script could read the network tab… but only for the current page.) There’s no direct access to the “network tab” or “console” in dev tools.
1 - payment by credit card - made entirely in the backend, so my user’s client does not have access to their API key.
2 - return the statement - done via the frontend where only the user can view their own key.
In this second example, what I was planning now is to make this call in the backend and use the “return data from API” to read it in the frontend. But in fact, WU consumption increases considerably. My main concern in reality is with the browser, concerned with what the user has installed as extensions. But from what you said, it doesn’t seem to be something simple, I should look for more information about it.
Exactly. And don’t forget that the request is made on server side even if you call it from frontend (you shouldn’t enable call directly from browser if possible because it doesn’t apply for this kind of API.)
Forgive me for another question, but why is the call made directly from the server if the user’s API key is not set to private? A simple query in the API service to return the account balance would be done via the frontend, right? I mean, in this example.