kyma
kyma copied to clipboard
kyma-project
Application Gateway handling redirects
Description
We need to set up and describe the policy of handling redirect responses in Application Gateway.
Reasons
There are cases in which external systems return redirects to Application Gateway. There were some reports that those redirects break the request flow - redirected requests no longer pass through the Application Gateway, and thus - do not contain authorization header / other credentials and fail. We need to check the exact behavior, decide how the redirects should be handled, and implement/document the solution.
The idea is to have that configurable per Application so that the user can choose whether they want Gateway to follow redirects or not. It can be included as a parameter in Application CRD, something like followRedirects (by default set to true).
Acceptance Criteria
- Approach to handling redirects in Application Gateway established
- Application CR parameter added
- Application Gateway uses the CR parameter to determine whether redirects should be followed or not
- Documentation updated (both parameter description in CR docs and the way of handling redirects in the Application Gateway)
A quick idea on how to set up a testing environment:
- Create an Application pointed to the httpbin
- Use the httpbin's redirect endpoint: https://httpbin.org/#/Redirects/get_redirect_to
- Redirect the call to other httpbin's endpoint supporting the authorization
- Response should contain all the request-related information
+1 report here about this issue. The current behaviour breaks the connection, for example, to SAP Field Service Management API (connected either manually or via SAP BTP). Checked 2.4.0 and 2.3.0 versions - same behaviour.
The flow is like this: in a kyma function, axios is used to do the requests. By default, axios client follows 5 redirects by itself. The explicit call from the function is done via central application gateway URL. CAG obtains OAuth token just fine, but while hitting targetUrl it gets back 308 response. So it passes back to the function and axios does the redirected call now directly to the location provided in 308 response. But apparently without authorization header. As can be expected, axios gets 401 from the new location.
If I set maxRedirects to 0 in axios client, I'm simply getting 308 response in one go.
The expected behaviour would be that CAG (go native http client?) handles redirects itself since it has authorization information and all. I tried a simple program in go to make the same call: the native http client in go follows redirects just fine as far as it fits into the exceptions described in go docs (passes to the same domain, doesn't pass to untrusted domains) passing authorization, custom headers, URL parameters and body along.
Just to give some context: it is a breakable change for us that blocks our migration from 1.24.8 (where the function and the same targetUrl work just fine) to 2.x version.
Happy to assist with reproducing the issue if needed.
Hey, @VishnAndr yes, this is exactly why the issue was created - there are issues with the FSM systems and their integration with Application Gateway, we are not sure why NGINX (which is on the FSM side) issues those redirects. Those were not there before and it seems like they are only present when Istio is involved in the flow.
We have tested multiple scenarios, turning off Istio seems to be the only work-around for now, but it still does not answer the question of why the redirects are there. My bet is that the mTLS between Envoy proxies inside Kyma somehow affects the requests on the network level and causes the NGINX to throw 308s (we've already checked the headers and they do not influence the flow).
I am in contact with the FSM guys, it's not an easy issue though. So far I was bounced between different people but I hope we will have some updates soon.
@janmedrek Cool! Looking forward for more info. But in general, redirects may happen for many reasons. Not only with FSM, but with arbitrary applications connected manually. Personally I think they still need to be handled and not passed on the functions.
@VishnAndr exactly, that's why we need to set up the proper way of handling those, this is already on top of our backlog for the next releases. 🙂
@VishnAndr sorry for the delay - it is the first thing waiting in line, as soon as we are done with the current work we will focus on this one.
We've added Location header rewriting to central-application-gateway. It is now possible to resolve redirects through the gateway. Here I described a basic scenario showcasing this feature. It's already present on main, it'll be included in the next release (with an appropriate mention in the documentation).
