"Force HTTPS" fails when combined with basic-authentication

[sailor16]

Steps to reproduce the issue

1. Setup Joomla 3.6.2 on an HTTPS enabled webserver.
2. Protect the installation path by webserver's basic authentication (apache http_auth).
3. If you try changing Force HTTPS (Administration, Global Configuration > Server) either to Entire Site or Administrator Only,
   1. the connection test will fail falsely (even when issued via https):
      "Warning: HTTPS has not been enabled as it is not available on this server."
   2. Force HTTPS will be forcefully changed to None irrespective of the intended value and even if it was on a higher level before:
      "Configuration successfully saved."

System information (as much as possible)

Joomla 3.6.2
PHP 5.6.9
Apache 2, AUTH_TYPE Basic

Additional comments

Issue follows up on https://issues.joomla.org/tracker/joomla-cms/9584#event-194294

Hints to fix it

Instantiating the test connection administrator/components/com_config/model/application.php line 121 ff might be extended to test the http_auth details of the existing session's connection - this could be a second test if the first one fails but before forcing None

[andrepereiradasilva]

Reference about joomla and HTTP Auth: #10128

[pdoolz]

I can complicate this matter a bit.
I have two joomla sites running on separate VPSs.
One was 3.5, upgraded through to 3.6.2. It has basic authentication enabled for the admin end, and a valid SSL cert. On this server, I can turn on or off the Force SSL without a problem.
My other Joomla site was 3.6.0 upgraded to 3.6.2 via 3.6.1. Incedently, the 3.6.1 and 3.6.2 automatic updates failed and I had to upload the patches separately. I only mention that because it may be relevant.
This site will not post html forms in IE and Edge, but works fine in Chrome, Firefox and Opera - I was trying to resolve this issue when I turned off Force SSL. It made no difference to the problem, so I tried to turn it back on and got the "HTTPS has not been enabled as it is not available on this server" warning - the site has a valid Let's Encrypt cert. I googled that error and found this Joomla bug.
Now I cannot force ssl on the site, even if I manually change the Force_SSL setting in the configuration file. It gets reset to 0.
It should be noted that the Force SSL setting was originally set and working fine (this would have been set in 3.6.0 - probably). However I cannot turn it back on.

The summation of all of this is that it, in my case anyway, it does not relate to the basic Auth in apache.
With Basic Auth on one VPS I can change the Force SSL setting
Without Basic Auth on anther VPS, I cannot change it.
Both have valid non-self signed SSL certs (why would you use a self-signed ssl when you can get them free - https://letsencrypt.org/)

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11735.}

[andrepereiradasilva]

Try changing global to configurações in site 1 to no https save and back to https. You will probably be locked in no https too because of the http auth

[pdoolz]

In my case, the site with the Force SSL error does not have the Basic Auth setting. That is what I tried to express in my comment, as it is different yet related to the submitted issue.

I should also mention that both sites work perfectly in SSL. When I submit the Force SSL setting in Global Configuration, I am using SSL.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11735.}

[andrepereiradasilva]

Thats how it works. The option label is "force" NOT enable/disable

[pdoolz]

@andrepereiradasilva I don't see how your comment is relevant to the discussion.
SSL is working - that is independent of Joomla. However, Joomla is testing to see if SSL is enabled, and that test fails incorrectly. When it fails, it changes the Force SSL setting back to None. As you can see from the attached picture, SSL is working perfectly, so there is an issue that needs to be resolved in Joomla.
The original issue here stated that it seemed to be related to Basic Auth, however, my testing would disagree with that assumption.

[andrepereiradasilva]

In your first site you have only http auth for admin dir. So it will Work.
You can see #9584

[pdoolz]

Nope, it is enabled on for entire site

[andrepereiradasilva]

One was 3.5, upgraded through to 3.6.2. It has basic authentication enabled for the admin end, and a valid SSL cert. On this server, I can turn on or off the Force SSL without a problem

[pdoolz]

As yes, sorry I misread your comment.
Basic Auth is only for the admin backend, and SSL is forced for the entire site.
However, I still don't see how this is relevant to the discussion above.
On my second site, with NO Basic Auth, and a valid SSL cert, I cannot force SSL - the test in joomla fails incorrectly. And that is what this discussion is about

[andrepereiradasilva]

Your second site don't have a clue. This issue is about the failing when all the site is protected with http basic auth. That is a confirmed issue.

[pdoolz]

Like I said at the beginning - I am having the same issue, but I am not using Basic Auth (second site). So the issue needs to be widened as it is not only related to Basic Auth.
Please don't comment unless you can provide helpful information.

[andrepereiradasilva]

I am free to comment and this is not the fórum for help. It you have other issue provide information on how to reproduce it in a new issue. Thanks

[andrepereiradasilva]

@sailor16 please test #11785

[sailor16]

@pdoolz
If you are unsure about the reason for the message, you should test the response code causing the Warning. To accomplish this, temporarily change the following code line to receive the numeric response code in the message and try again:
administrator/components/com_config/model/application.php line 156
$app->enqueueMessage(JText::_('COM_CONFIG_ERROR_SSL_NOT_AVAILABLE'));
to
$app->enqueueMessage(JText::_('COM_CONFIG_ERROR_SSL_NOT_AVAILABLE') . ' - Response code was: ' . $response->code);
Open a new issue with any response code not reading '401' (Unauthorized) and provide information on how to reproduce it.

@andrepereiradasilva
Thanks for the hint to #10128.
I created a code fix that does the trick for my apache server (getting the current browser session's basic authentication credentials ref. htaccess/htpasswd)

The following codelines should be inserted at administrator/components/com_config/model/application.php line 142ff (before throwing an error on status code 401)

// If available and htaccess protected, test with current credentials
if ($response->code == '401') {
    $options->set('userauth', $_SERVER['PHP_AUTH_USER']);
    $options->set('passwordauth', $_SERVER['PHP_AUTH_PW']);
    $response = JHttpFactory::getHttp($options)->get('https://' . $host . JUri::root(true) . '/', array('Host' => $host), 10);
}

This is not (yet) a general solution: these php server variables are not always set like this in all distributions and scenarios (see e.g. http://stackoverflow.com/questions/3663520/php-auth-user-not-set).
I presume there is (should be) a Joomla object holding this sort of browser credentials, but I cannot spot it.
Once this is generalised, it might be worth a Pull Request.

With respect to the issue part (ii) ($force_ssl is downgraded automatically) this might require a short discussion.

[sailor16]

@andrepereiradasilva
Great - I guess that is the way to go; more general (independent of current credentials), but it should be rare to see different basic auth credential philosophies for front- and backend that would call this an unexpected behaviour.
It works for me :-)

[zero-24]

So we can close here as the PR fiXes the prolem?

[andrepereiradasilva]

yes

[brianteeman]

Closed