Closed SysEngDan closed 2 years ago
Thanks for the great feedback.
This is definately something that we should support as its pretty much the standard way of routing in the cloud native era.
Should this be considered a bug since proxy support is already written in readme.md?
“For use in production environments, QueryTree should be run behind a reverse proxy such as nginx. For more information on hosting QueryTree using nginx see: https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction
This project was originally refactored form a windows only .NET stack back in the day so theres definately lots of nice .NET core features we've missed.
Looks like it s amatter of enabling the forwarding headers. It's not something that's automatically taken care of:
using Microsoft.AspNetCore.HttpOverrides;
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
app.UseAuthentication();
@SysEngDan could you give d4software/querytree:reverse-proxy
a go?
I gave it a shot but I'm still saying the same response. What happens is that the application redirects from the initial request (https;//reports.example.com) to this https://reports_example_com_app/Account/Login?ReturnUrl=%2F (that's the docker service name). This tells me that the application isn't honoring X-Forwarded-Host (which contains the original hostname).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I'm running QT with Docker, using image d4software/querytree:c63e66f. I have many, many website running behind the reverse proxy which work without issue. When configuring QT with a simple, basic proxy_pass config, the QT redirects to the Docker service name. It seems like out of the box, QT doesn't honor X-Forwarded-For and Proto headers.
Any advice?