How to get redirects right ?

[glucaci]

Hi,

We are using the proxy in front of 3rd party services witch dose not support OIDC.

Below I have a configuration example which I don't know how to extend it in order to handle 3rd party service redirects.

{
  "Routes": [
    {
      "RouteId": "app1",
      "ClusterId": "app1",
      "Match": {
        "Path": "/app1"
      },
      "Transforms": [
        { "PathRemovePrefix": "/app1" }
      ]
    },
    {
      "RouteId": "app2",
      "ClusterId": "app2",
      "Match": {
        "Path": "/app2"
      },
      "Transforms": [
        { "PathRemovePrefix": "/app2" }
      ]
    }
  ],
  "Clusters": [
    {
      "ClusterId": "app1",
      "Destinations": {
        "app1_destination1": {
          "Address": "http://app1-kube-service.namespace"
        }
      }
    },
    {
      "ClusterId": "app2",
      "Destinations": {
        "app2_destination1": {
          "Address": "http://app2-kube-service.namespace"
        }
      }
    }
  ]
}

Everything is working fine until the app is doing a redirect.

e.g.

1. GET /app1
2. GET http://app1-kube-service.namespace ( Response 302 , location: /login )
3. GET /login ( how to modify this redirect to go to /app1/login ? )

[Tratcher]

You have two choices to address link generation issues like this:

A) Flow the value "/app1" to the destination as a request header "x-forwarded-pathbase" or similar. This could be added with a header transform. The destination can consume this value and use it when generating links and redirects. There are some examples of this from the receiving end here: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.1#deal-with-path-base-and-proxies-that-change-the-request-path

B) Re-writing links and redirects in the response using a response header transform. We haven't written a transform for this yet, we'd need to write one that derives from ResponseHeaderTransform. #60 tracks how we'd integrate custom transforms with config, at the moment there isn't a good way to add your own custom transform to a route.

A is recommended as both a short term (you should be able to use it now) and long term solution since creating the correct links and redirects the first time is much less error prone than trying to rewrite them later. B should only be used if you can't modify the destination app to generate accurate links/redirects. Note B would still only be able to handle redirects, not links in the body. Rewriting the response body is a much harder problem, and not one YARP intends to tackle any time soon.

[glucaci]

Thank you! For my scenario will remain only B because I have no control on the destination app.