Handling 302 redirects for login

[conficient]

We are trying to use YARP in front of an ASP.NET WebForms app using Identity and having an issue with redirect responses (302) using the 'internal'

If a user isn't logged in, it sets LoginPath = new PathString("/user/login") in our Startup - however the user gets the internal host URLredirect in their browser, instead of the proxy server.

Scenario:

1. User navigates to https://mysite/ which is handled by the proxy.
2. It forwards the request to http://internal:8001/ - the WebForms host
3. This sees the user is not authenticated, so returns a 302: redirect to http://internal:8001/user/login
4. The proxy appears to pass this URL unedited back to the user, so they are unable to see the page

If we navigate directly to the correct page, e.g. https://mysite/user/login the correct page is shown and the proxy works correctly.

[samsp-msft]

The use of a proxy will not be transparent to the back-end site, and the site needs to be aware of the proxy. The proxy will inform the destination of the original connection information using a series of x-forwarded-* headers.
ASP.NET Core has a middleware that will update the context values based on these headers - https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0. I think the login components will be using the context values so this should wire it up correctly, assuming you add the middleware on the backend site.

[conficient]

Thanks for the suggestion. Can't add this middleware as my back-end is .NET Framework + WebForms. I tried to figure out how ASP.NET used to handle reverse proxies but wasn't able to find a suitable example to copy.

Instead I found that I can modify the redirect for the login using the .OnApplyRedirect action on the CookieAuthenticationProvider. It's a bit of a hack but it reads the X-Forwarded-Host value and changes the redirect to use the proxy's path.

[Tratcher]

It's true that there's no existing middleware implementation for .NET Framework, but if you're using CookieAuthenticationProvider then you're still using OWIN middleware. The recommendation there is to write an OWIN middleware that reads the x-forwarded-* headers and updates the associated request fields. This helps avoid having to customize all the other components in the pipeline. Note setting the host is likely not enough, you also likely need to set the scheme.

[conficient]

Thanks for the explanation! Time to brush up my IHttpHandler skills..