-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Umbrella to add X-Api-Key header when OPTIONS request is handled #391
Comments
@matleppa have you tried the option 2 work around mentioned in this issue? I'm running into this myself. The history of this issue seems to go back a while and I'm not sure if the work around mentioned is still the right option. Would be great if there was an option out of the box for this. If the work around is still good, I'm happy to document it on the wiki. |
@matleppa, @ccsr, @adborden: Whoops, I hadn't realized this was still an issue lurking from the closed #116. I think we can definitely come up with a better, more automatic solution. @matleppa: Although, if you're only trying to achieve this for Swagger integration, have you considered passing the API key in the URL query string instead of HTTP header? That should sidestep this OPTIONS issue (although, I do agree we should come up with something more automatic). Here's an example Swagger page that integrates API keys that are passed via GET query parameters: https://developer.nrel.gov/docs/cleap/buildings_and_industry/ The underlying Swagger doc is at: https://developer.nrel.gov/docs/cleap/buildings_and_industry/spec.yml But I believe the important piece is: securityDefinitions:
api_key:
type: apiKey
name: api_key
in: query
security:
- api_key: [] @adborden: That second option outlined is still valid. I think there might technically be slightly easier ways to achieve this using the "Override Response Headers" functionality that API Umbrella now has (it didn't exist at the time), but I think that would still require the API backend respond to the OPTIONS request. More generally, in terms of how we might address this, I think you've laid out some good options, @matleppa. I think we need to be careful to think about the ramifications of messing with this behavior, but I guess my initial quick take might be to implement the following functionality:
So basically, I think if we implemented items 1 & 2, that would go a long way to making the If we also implemented item 3 as an option, then I think that would also give an easy path to supporting proxying to API backends that don't respond to OPTIONS at all. Does all that seem to make sense? Any other thoughts or ideas? |
@GUI Thank you for your good answer with great analysis of solution alternatives. This CORS-OPTIONS came up when using the Swagger, but I think that same problem will be faced when calling APIs via API Umbrella from other UIs (using browser), as well. So, I agree completely with you about items 1 & 2. About item 3. 3+. One other possibility could be to possibility to have a configurable append_response_headers functionality with which different headers could be added into original response from API. This could be used in case API responds, but it can only partially indicate support in OPTIONS response. All in all, 3 and 3+ were more nice-to-have functionalities, with which API Umbrella tries also take care of part of APIs business in call API via a proxy environment. So I vote for 1 & 2. |
Change in original issue: API Umbrella to fix badly behaving API Backend.
There are problems when e.g. an API call is done by Swagger and API key is used.
Instead of successful response, thew outcome is TypeError: Failed to fetch.
My current understanding is that the flow is following:
Solved
Solved
2. Browser sends an OPTIONS request
Problem
3. API Umbrella accepts and conveys OPTIONS request to API. The X-Api-Key header is included in A-C-R-H header (at least it should be there according to specification)
4. API responds to OPTIONS request, but response may not contain X-Api-Key header in Access-Control-Allow-Headers
5. Browser does not send original GET request, because of X-Api-Key header mismatch between A-C-A-H in OPTIONS response and A-C-R-H in GET request.
So it should be up to API to respond with accurate A-C-A-H list.
However, because the API does not necessarily use API key, but API Umbrella is requiring it, the API may not be properly implemented handling of OPTIONS request, so maybe API Umbrella could be used to solve the problem.
Proposal to a new functionality
First thoughts about solving problem were following:
I was checking API Umbrella configuration, the override_response_headers functionality, but it is not enough, because there might be different list of custom headers in response depending on API.
So needed new functionality in API Umbrella configuration were e.g. a new option, such as append_response_headers, which would be used to add custom headers to original OPTIONS response from API before conveying it to browser.
Second thought was, that could API Umbrella have this kind of functionality:
This way the browser were informed about the support for headers and it can continue the operation.
The text was updated successfully, but these errors were encountered: