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
[TT-955] bug: CORS options_passthrough on Non OPTIONS requests #1506
Comments
I think your second solution (certain conditions create an options request) is the most spec compliant. IMO, the gateway should act just like any other user agent, that basically means that when options pass through is enabled, it should be constructing pre-flights on behalf of the inbound request and sending those on. We can either make these conditional (I.e. on errors only), or make them constant, so they run on every request type. Either way the pre-flight should go from gateway to upstream based on the real request made by the downstream user-agent. This basically means implementing the pre-flight spec into an http client. When to trigger this client can then be a secondary option. |
What about other response codes? they would just be blocked?
Sorry, haven't thoroughly checked, this is off the top of my head |
I'm facing the same issue when Tyk block the request and return a forbidden response. No CORS Headers because request never hit the upstream. |
I also have this issue with rate-limited 429 responses. Regarding solution 1, I recall that with |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs, please add comments to this ticket if you would like it to stay open. Thank you for your contributions. |
not stale (ZD ref 11458) added TT-955 |
When
Enable CORS: false
andOptions Passthrough: true
. In the scenario where the gateway is short-circuiting the proxy, for example due to failed auth, the response headers do not contain required CORS headers.It is expected by Browsers that the SAME CORS headers returned from an OPTIONS request will be returned on a POST request for example.
Steps to Recreate:
Browser sends preflight
OPTIONS
request to GW, GW transparently reverse proxy preflight request to upstream. CORS headers returned.Browser sends actual request to Gateway. But with invalid credentials - which means 4xx failure.
This is because the gateway has short-circuited the connection and never hits the upstream in order to get the CORS headers.
Possible Workarounds / Thoughts / Considerations:
1. Enable CORS in the gateway as well as options_passthrough.
This will enable, in the event of a non-simple and non-options request for Tyk to return it's own CORS headers.
Pro: Simple solution.
Con: Need to configure to return exactly same CORS headers as was provided by the initial OPTIONS request, otherwise browser will complain.
2. Given certain conditions, perform OPTIONS request to upstream and merge CORS headers with error response
Pro: Should be correct every time
Con: Complexity from code perspective, error handling for CORS request, multiple OPTIONS requests to upstream
3. Cache initial OPTIONS request
When an OPTIONS request is performed, it is implied that a follow-up request will be made. For a short period of time, we can cache the headers of the preflight response.
When real request is sent, if short-circuiting, merge CORS response headers from cache with error response.
Pro: Most elegant solution
Con: Respecting CORS cache TTL, increased code complexity, possible edge cases.
The text was updated successfully, but these errors were encountered: