422 Error When Trying to Use OpenAPI 3.1.0 Resource

đź’¬ Queries and Resources
1
  1. My goal: Use an OpenAPI 3.1.0 JSON file as a Retool resource (Per documentation)
  2. Issue: When attempting to connect to the resource, we get the following error in the Retool console:
Test connection failed (15.429s):Error: Could not establish a connection. Try checking your database firewall configuration and whitelisting Retool's IP Address.
HttpError {statusCode: 422, payload: Object}
statusCode: 422
payload: Object
statusCode: 422
error: "Unprocessable Entity"
message: "Could not establish a connection. Try checking your database firewall configuration and whitelisting Retool's IP Address."
data: null
  1. Steps I've taken to troubleshoot: We're able to connect to and use the OpenAPI resource via Postman and CURL. We've reviewed our CORs and IP allowlist configuration as well, and confirmed that Retool should be able to connect.
  2. Additional info: None.
2

clear your cache

3

:thinking: It's still an issue with the cached clear, in an Incognito window, new browser, etc.

4

Hi @steveaustin,

Apologies for the issue. Very odd that even with the Retool IP whitelisted that the firewall is still catching and rejecting the incoming requests.

Can you confirm what IPs you have white listed? I have another user with a similar issue and I am checking internally if there is a unique quirk to how OpenAPI queries are sent :thinking:

Are you able to query the routes via a REST API query?

5

We have the following allowlisted:

35.90.103.132/30
44.208.168.68/30

What's confusing, though, is that the OpenAPI resource is not hosted behind a firewall; it's publicly available on the internet, requiring authentication via a username and password. There should be no allowlisting required, and I assume just a CORs validation.

6

Hi @steveaustin,

Thank you for the details.

I was just going through your org's logs in Datadog and it looks like at least one of the errors getting passed back to Retool from the server had an error code of 401.

Could you double check that the auth username and password are correct?

7

Thanks for the help, and apologies for the delayed response!

We investigated even further here and found:

  1. We confirmed that the credentials we provided are correct
  2. Via server logs on our end, we’ve confirmed that the Retool OpenAPI integration is not including the Basic Auth headers for authentication in the request.
  3. When authentication is removed from our OpenAPI route, we can connect to and use the resource.
8

Hi @steveaustin !

No worries for the delayed response.

Great work figuring out that the Basic Auth headers were not being included in the request, that is very odd. I am curious as to what could have caused that to happen :thinking: seems to definitely be the culprit.

Does your use case allow for authentication to be removed? I can check with our team to see if we can reproduce the auth headers not being included or if there are more details this either being a bug and hard limitation or if there is a known work around or anything that can be done to allow for auth to work as intended.

9

Unfortunately, we do, as it’s the OpenAPI specification for our own resources, which we’d prefer not to be public. If you wouldn’t mind checking with the team, that would be great! We’ll separately see if a different authentication method other than Basic authentication works here.

10

This was a mistake on our end, as we confused:

  1. Authentication to access the OpenAPI resource
  2. The resource’s own authentication in making requests

We are able to access our authenticated OpenAPI resource with:

  1. Checking “Forward headers when fetching OpenAPI spec”
  2. Adding the custom header with key Authorization and value Basic <Base 64 encoded username:password>

Thank you for the help!

1 Like