Goal: I want to use our internal admin API as a data source. The internal OpenAPI spec is secured by a basic authorization.
Steps: I tried using the URL syntax for basic authorization https://username:password@our.url.com/api/doc.json and specifying and forwarding the base64 encoded Authorization header when fetching the OpenAPI spec. The Authorization header solution works, but I'm unable to overwrite the header value in a later custom Auth flow, which needs a Bearer token.
The easiest solution would be overwriting the Authorization header after the initial spec call with the actual Bearer auth_token value. I wasn't able to find anything in the docs or the forums which describes if and how that would be possible.
Can we see your custom auth set up as well? Is that the resource spec URL? The custom auth process can call other APIs that are different from the spec url in order to obtain bearer tokens:
Here's our custom auth docs. The auth process should be set up in the custom auth steps - as needed for your specific api. Any variables you've created in the custom auth flow can be referenced in the headers section
Came across this because I think it's related, but not entirely...
Is custom auth necessary for a client credentials flow with the OpenAPI resource? The option is not available in the immediate dropdown, and it seems that Retool does not properly handle acquiring the access token. The same exact auth setup works perfectly fine in a REST resource, however.
the custom auth flow isn't the problem. The problem is that the Spec URL isn't able to use URL based Basic Authentication, so I have to set Authorization headers which are forwarded (checkbox), when fetching the specs.
At a later point I'm unable to overwrite the full Authorization header that I set earlier in the form.
A possible solution would be a default value for the variable, used in the auth header value, but your UI does not allow handlebar notation at this point.
Hey @Amir ā would you be able to put the entire flow in the custom auth section?
Custom Auth Flow
Authenticate OpenAPI spec with custom API request using username/password in url
Save returned bearer token as auth_token variable
OpenAPI Resource config
3. Add Authorization: Bearer auth_token to your headers
In this setup, I do not think you need to forward headers when fetching the OpenAPI spec since you handle the username/password auth for the spec in Step 1 (assuming that call returns a bearer token for authenticating with your actual API).
Iirc the headers in the OpenAPI config are for the resource specified in your OpenAPI config (i.e. the actual API you want to call), not for retrieving the spec itself ā unless they use the same authentication method, in which case you can just forward headers.
So once you retrieve the bearer token by calling your spec endpoint with usr/pass (Step 1), you can just save it (Step 2) and pass it as the resource header as Authorization: Bearer auth_token (Step 3)
Caveat
The only thing Iām not sure about is whether the authentication with the spec itself will be retained. Worth a shot still.
You can check out my post above for ways to debug your Retool auth flow if you need better visibility.
āā
Iām making a few assumptions based on what you wrote, but hopefully this helps!
Also, do you have control over the auth flow for both the spec and service?
Alternatively, if your OpenAPI spec endpoint is not the same one that returns your bearer token, you could try to proxy the request through a Retool workflow:
Create a workflow that authenticates with your spec (via usr/pass) and returns the .json object.
Add this Retool workflow endpoint as your specification URL in the resource config (no need to handle usr/pass auth ā you already have the json from the workflow)
Authenticate as usual with your actual API resource and pass the bearer token through the OpenAPI resource config header
Again, see post above for an example of how to proxy with workflows.
As you guessed correctly, the spec URL and the endpoint are not the same. We are trying to whitelist the IP range on the URL spec, but without luck so far.
I just tried using the workflow proxy as a solution. Theoretically it should work, but it seems that the response format isn't accepted by the resource spec. When opening the proxy workflow URL in my browser it shows the JSON, but when testing the resource connection it returns an unknown error.
Hmm - I can't tell for sure from the screenshot, since it seems like only part of the error message, but it looks like the OpenAPI resource is failing to retrieve the reference object (App\\DTO\\View\\SelectView) that defines this part of the schema (i.e. the $ref is pointing to an object that doesn't exist in the schema).
If you're able to share a redacted version of your OpenAPI schema JSON, I may be able to help further.
How are you creating the OpenAPI schema, anyways (manual or auto-generated)? Does it work with other services (aside from Retool), like Postman?
The reference is fine and worked when tuning the configuration on retrieving the spec alone. But this configuration fails to call any Api endpoints obviously.
Yeah, it sounds like this solution may not be ideal. It assumes that your Retool Workflow endpoint can dereference & retrieve the rest of the information, which it can't unless serves all of those files (like a dedicated server would).
Do you have control over this OpenAPI server and how authentication is handled? That would be the easiest way to make this work (i.e. change the auth mechanism), but I understand that's not always possible.
