Fix reverse proxy subpath support using External_Webserver_address

[Leolebleis]

Your checklist for this pull request

• Make sure your name is added to Contributors file /Plan/common/src/main/java/com/djrapitops/plan/delivery/rendering/html/Contributors.java
• No locale changes

Description

When Plan runs behind a reverse proxy at a subpath (e.g. /minecraft/stats/), External_Webserver_address was only consulted when the webserver was disabled. With the webserver running, both HTML asset paths and PLAN_BASE_ADDRESS used the internal address (e.g. http://localhost:8804), breaking static asset loading, React Router navigation, and API calls (wrong protocol/path).

Changes:

• Addresses.getExternalAddress() — new method returning External_Webserver_address when set to a non-default value
• BundleAddressCorrection.getWebserverBasePath() — prefers external address base path for HTML/JS/CSS path rewriting
• ResponseFactory.replaceMainAddressPlaceholder() — prefers external address for PLAN_BASE_ADDRESS injection

Tested on a live deployment (Plan v5.7 b3288 behind nginx HTTPS proxy at a subpath). Unit tests included.

[AuroraLS3]

Alternative_IP.Address is used for this purpose - External address is intended for use when Export is being used

[Leolebleis]

Alternative_IP.Address is used for this purpose - External address is intended for use when Export is being used

@AuroraLS3 Ah I see, thanks! I originally tried Alternative_IP but ran into two issues with HTTPS reverse proxy setups:

1. Mixed content: Alternative_IP gets prepended with Plan's webserver protocol (http://), so PLAN_BASE_ADDRESS becomes http://example.com/plan. On an HTTPS page, API calls to http://... are blocked as mixed content by browsers.
2. getMainAddress() checks DB first: BundleAddressCorrection.getWebserverBasePath() uses getMainAddress(), which queries plan_servers before checking getAccessAddress(). The DB stores the internal address (http://localhost:8804), so Alternative_IP never affects path correction.

External_Webserver_address avoids both issues since it includes the correct protocol (https://) and isn't overridden by the DB lookup.

Would you prefer a different approach — e.g. making Alternative_IP protocol-aware, or having getMainAddress() also consider Alternative_IP?

[AuroraLS3]

When using reverse-proxy based https you can set up Plan to assume https with proxy-mode: https://github.com/plan-player-analytics/Plan/wiki/SSL-Certificate-%28HTTPS%29-Set-Up#if-behind-a-proxy

[AuroraLS3]

This test covers regressions for reverse-proxy behind subdirectory
https://github.com/plan-player-analytics/Plan/blob/master/Plan/common/src/test/java/com/djrapitops/plan/delivery/webserver/ReverseProxyRegressionTest.java

[Leolebleis]

Ah ok thank you :) I need to AFK for a bit but will check later, I think I tried that and ran into issues

Will get back to you asap!

[AuroraLS3]

The issue you ran into is likely a caching issue (Another user was having this today) - The javascript file that contains PLAN_BASE_ADDRESS is cached by the browser and change to proxy mode is not reflected in the address until cache is cleared.

Why this issue wasn't run into before is that the old bugged code defaulted to using relative address when the configured address "Didn't match", which meant that the site still loaded, but now with the bug fixed it detects the address as correct and tries to serve HTTP content in HTTPS website which the Browser blocks.

This needs to be fixed in the cache logic for static javascript files rather than configuration settings, so I will close this PR - I have applied this fix in 1a8bac8