reverse proxy support inconsistent and undocumented

[robertmx]

Dear developers,

thank you for working in stirling PDF. Unfortunately the support for reverse proxys is broken and undocumented. The following problems exist:

1. There is no documented way to set the server name and port of sPDF. It is unclear which headers are taken into account and how sPDF determines it's own server name. That results for example in wrong redirects as mentioned in Request to Cancel v2 Redirection for Icons When Using Non-Standard Ports #1113

2. URLs throughout the website are constructed inconsistently. Thus the url base settings are ignored sometimes (for example the apple-touch-icon and the favicon and the bootstrap icons)

It is possible to fix part of these problems with heavy header rewriting and mangling on the reverse proxy. Because the documentation is non-existent, that is a tiresome try-and-error method. I was able to fix problem 1 but not all of problem to with that approach.

That leads me to the conclusion, that the URL routing logic needs consolidation and especially all generated links in the web page need to calculate their values from that central routing information table, which keeps track of the site name(s), port, scheme and uripath.

[Frooodle]

Just to confirm is this in regards to Stirling-PDFs security jar/mode?
I agree the URL redirecting has major issues on security jars side, Do you also mean non security/login mode?

[robertmx]

Hello,

yes i refer to the non-security / non-login mode. I have an identity aware proxy in front who takes care of authentication and authorization.

I think the low-hanging fruit would be to fix the absolute paths in the templates such as these:

`
link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png?v=2"

link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png?v=2"

link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png?v=2"
`

which obviously wont work with some non-root server path. But the bigger problem is sPDF generating some backend-only links with a local address (127.0.0.1) which are impossible to resolve from the client. And the header and location rewriting to fix that is exceptionally ugly.

[Frooodle]

just removing the / should solve that, just merged to develop

[mikebakke]

Sorry to dive in. Will that also fix reverse proxy in secure mode? I am using haproxy and it is unable to load at all presently.

When connecting I get the sign-in screen although the image does not display but entering credentials tells me the server cannot connect. Local mode is absolutely fine - thank you for this utility.

[Frooodle]

No sorry

[mikebakke]

ok thank you - I will try running insecure once the new image drops.