Forum Post Assistant too many redirects

[frostmakk]

Intended for a future to-do list: Improve SSL detection? https://forum.joomla.org/viewtopic.php?f=806&t=982748

[RussW]

Hmmm... Yes, I'll have to have a deeper look at this and see if it is possible to determine the status of the connection between the sites webserver and any load-balancer or reverse proxy infront of the site. It seems odd that the forward proxy provides public SSL connection but non-SSL back to the webserver, but in saying that I think it is also possible to configure a CDN connection in this manner if the webserver host does not provide an SSL certificate and the CDN SSL is used instead. I'll need to try and setup some test-beds with this mixed configuration. This may take some time.

Note To Self: check for FORWARDER PROTOCOL, something like;

$isSecure = false;
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') {
    $isSecure = true;
}
elseif (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' || !empty($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] == 'on') {
    $isSecure = true;
}
$REQUEST_PROTOCOL = $isSecure ? 'https' : 'http';

[RussW]

Ok, new branch loopProtection is available for testing and comment - please be aware this is quite hard to test.

I've added some tests to try and detect any upstream servers (proxy/caching/cdn/load balancer) and if the Joomla! configuration has the proxy_enable configuration variable enabled.

• if $force_ssl is enabled (1, 2), let the auto-redirect occur anyway as SSL is already in use

• if $proxy_enable is enabled AND $force_ssl is not (0), don't redirect

• else check if we have any headers from an upstream server, if so, don't auto-redirect and let the upstream server handle the protocol

• then if we haven't detected any upstream server(s), attempt to then discover if the users hosting server is SSL capable with a valid certificate and allow the auto-redirect

PHP provides the following related global variables to use; I've left these echo'ing at the top of the page for testing purposes, standard results should all be empty, if there is an upstream server, depending on the type, one of these will contain an IP Address of the hosting server

CLIENT_IP, FORWARDED, FORWARDED_FOR, FORWARDED_FOR_IP, VIA, X_FORWARDED, X_FORWARDED_FOR, HTTP_CLIENT_IP, HTTP_FORWARDED, HTTP_FORWARDED_FOR, HTTP_FORWARDED_FOR_IP, HTTP_PROXY_CONNECTION, HTTP_VIA, HTTP_X_FORWARDED, HTTP_X_FORWARDED_FOR

As for testing, well, initially, just the usual, make sure it works as expected without any upstream server

• change the force_ssl and proxy_enable settings in Global Configuration

• then if you have any sites that have a CDN or other upstream server, try again and if the upstream server provides the SSL Certificate, enable/disable the force_ssl variable in the global configuration

• if you know anyone else with load balancers, cdn, caching proxies, ask if they can do the same

The real difficulty here is that with browser caching being very aggressive these days, you may find the results are not as expected when testing non-SSL as the browser may auto-redirect to the known SSL site anyway. In the browser settings you may be able to enable/allow non-SSL access if needed and/or keep clearing cache and/or keep restarting your local test servers) I've also found that renaming the fpa-en.php may help with aggressive browser caching also.

[RussW]

With the latest branch update (5th Dec - commit https://github.com/ForumPostAssistant/FPA/commit/2e16f0151a185d429ff6355f6e79f800fa80c346 ) do you think it is worth asking in the Forum (maybe the issue OP) and maybe the FB Support Group (I'll do these folks) for volunteers to test the "loopPROTECTION" branch if they have load-balancers, proxies or CDN's on their instances?

I'm thinking if we know folks with AWS Cloud Accounts with load-balancers, CDN users that make use of the CDN's SSL Certificate instead of the local hosts and user that have Varnish installed.

Thoughts? Better suggestions to get this frontend-server fix tested?

[mandville]

Like I did here.

https://twitter.com/mandville/status/1334442789711589377?s=19

On Fri, 11 Dec 2020, 07:47 Russ Winter, [email protected] wrote:

With the latest branch update (5th Dec - commit 2e16f01 https://github.com/ForumPostAssistant/FPA/commit/2e16f0151a185d429ff6355f6e79f800fa80c346 ) do you think it is worth asking in the Forum (maybe the issue OP) and maybe the FB Support Group (I'll do these folks) for volunteers to test the "loopPROTECTION" branch if they have load-balancers, proxies or CDN's on their instances?

I'm thinking if we know folks with AWS Cloud Accounts with load-balancers, CDN users that make use of the CDN's SSL Certificate instead of the local hosts and user that have Varnish installed.

Thoughts? Better suggestions to get this frontend-server fix tested?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ForumPostAssistant/FPA/issues/108#issuecomment-743032989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG2A6PQNLTKVBOXYLRZIJ3SUHFARANCNFSM4TP3MN4Q .

[RussW]

awesome, thank you mate

I was going to post something like the following in the FB Group specifically for the frontend-server loop issue

---

Friends, Romans, Countrymen, reprobates, dodgy characters and anyone else that might just give a crap;

The FPA (Forum Post Assistant) Project are looking for volunteers to test a bug-fix (no prodding, poking or jabs required and no pain involved)...

Does your site run behind a frontend-server?

and use SSL, either at the localhost, at the frontend-server or both. (nginx Reverse-Proxy, Cloud Load-Balanced, CDN, Varnish Caching Server or similar)

We've had an issue brought to our attention where the FPA potentially causes a "500" server error following a "too many redirects" message in some configurations where a frontend-server is involved.

We have a proposed solution! 

But it needs testing across these configurations and we do not have the physical resources available within the team to confirm the bug-fix in all configurations.

How To Test: Download the development branch of the FPA from the Github "loopProtection" branch ( https://github.com/ForumPostAssistant/FPA/tree/loopProtection ) and simply run it against your site ( FPA Documentation can be found at : https://forumpostassistant.github.io/docs/ )

Tell Us What Happened: If the FPA runs fine and informs you that you are behind a frontend-server without looping, or if the FPA loops, let us know your results at https://github.com/ForumPostAssistant/FPA/issues/108 describing your configuration and frontend-server type.

[RussW]

Like I did here. https://twitter.com/mandville/status/1334442789711589377?s=19 … On Fri, 11 Dec 2020, 07:47 Russ Winter, @.***> wrote: With the latest branch update (5th Dec - commit 2e16f01 <2e16f01> ) do you think it is worth asking in the Forum (maybe the issue OP) and maybe the FB Support Group (I'll do these folks) for volunteers to test the "loopPROTECTION" branch if they have load-balancers, proxies or CDN's on their instances? I'm thinking if we know folks with AWS Cloud Accounts with load-balancers, CDN users that make use of the CDN's SSL Certificate instead of the local hosts and user that have Varnish installed. Thoughts? Better suggestions to get this frontend-server fix tested? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#108 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG2A6PQNLTKVBOXYLRZIJ3SUHFARANCNFSM4TP3MN4Q .

You're my Heroin @mandville :D

[RussW]

Results So Far

Please feel free to update as required

Online Testing

• Linux : Apache Simple SSL Redirect [no proxy] :white_check_mark:
• Linux : Apache / CDN SSL Redirect + Notice :white_check_mark:
• Linux : Apache / nginx Reverse Proxy SSL Redirect + Notice :white_check_mark: - Thanks @StefanSTS
• Apache / Load-Balancer SSL Redirect + Notice
• Apache / Varnish Caching Proxy + Notice

Localhost Testing

• Linux / MacOS : Apache Simple SSL Redirect [localhost] :white_check_mark:
• Linux / MacOS : Apache NO SSL Redirect [localhost] :white_check_mark: