1

I have an apache configuration with reverse proxy (IP of this server: 192.168.1.82) to handle my new D9 server:

192.168.1.82 : 443 is passed to 192.168.1.87 as HTTP(80)

<VirtualHost *:443>
    ServerName www.mydomain.be
    ServerAlias mydomain.be
    NameVirtualHost www.mydomain.be

    ProxyPreserveHost On
    ProxyPass / http://192.168.1.87:80/
    ProxyPassReverse / http://192.168.1.87/
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off
    SSLProxyVerify none
    ...
</VirtualHost>

I think it is called SSL Termination

192.168.1.82 : 80 is redirected as https (443)

<VirtualHost *:80>
    ServerName www.mydomain.be
    Redirect permanent / https://www.mydomain.be/
</VirtualHost>

192.168.1.87 : settings.php

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = [
  '192.168.1.82',
];
$_SERVER['HTTPS'] = 'on';
$settings['ssl'] = TRUE;

Unfortunately the autocomplete feature of an entity reference field request a non https (unsecure) endpoint (Mixed content):

http://www.mydomain.be/fr/entity_reference_autocomplete/node/default:node/3veI...I?q=t

What can I do to force the https... I will accept the most ugly hack if it is working (yes, I am here)

Test 1: ProxyPass https instead of http [will not work, see below]

I have adapted the 82 virtual host as follow;

SSLProxyEngine on
ProxyPass / https://192.168.1.87/
ProxyPassReverse / https://192.168.1.87/

=>This time I don't have the mixed content problem, but I have ERR_TOO_MANY_REDIRECTS again for this entity autocomplete endpoint

Test 2: hack Symfony\Component\HttpFoundation\Request::isSecure()

Here is my new isSecure() function:

public function isSecure(){
  return TRUE;
}

By doing this, the autocomplete url use https, but this time, I got ERR_TOO_MANY_REDIRECTS

GET https://www.mydomain.be/fr/entity_reference_autocomplete/node/default%3Anode/3ve...I?q=T net::ERR_TOO_MANY_REDIRECTS

I have really no clue from where it can come

4
  • Have you tried enforcing this at the htaccess level?
    – Kevin
    Feb 12 at 14:47
  • good idea: how to do it? Many thank by advance for the tip!!!
    – Baud
    Feb 12 at 14:52
  • @kevin: this is not an https redirection, this is a SSL termination: 82 is handling encryption and it pass the result (ProxyPass) to 87 as plain http. My setup looks nearly good as everything works execpt the mixed content. I don't know if this is a Drupal problem or an Apache problem
    – Baud
    Feb 14 at 17:09

2 Answers 2

1

The htaccess file in Drupal should be able to force all traffic as HTTPS. There are some comments in the file, but something like this should work (used in several projects):

  # Force all traffic to HTTPS, except a local instance
  RewriteCond %{HTTPS} off
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteCond %{HTTP_HOST} !^local\.dev\.domain$ [NC]
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]




  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

The third line is optional - it would exempt a local dev environment from the rewrite. If you use a local SSL, you can omit that line.

If Apache is serving all requests, it will pass through these rules, evaluate them and do the rewrite.

You can test rules here: https://htaccess.madewithlove.com/

Here is the test: https://htaccess.madewithlove.com?share=69ce1303-b1af-4041-aecf-a32f2ecd1bfb

enter image description here

6
0

Try to set X-Forwarded-* headers in the Apache reverse proxy:

<VirtualHost *:443>
    ServerName www.mydomain.be
    ServerAlias mydomain.be
    NameVirtualHost www.mydomain.be

    ProxyPreserveHost On
    ProxyPass / http://192.168.1.87:80/
    ProxyPassReverse / http://192.168.1.87/

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

These are the headers which the reverse proxy configuration in settings.php needs.

You can check the presence of the headers at www.mydomain.be/admin/reports/status/php in the section HTTP Headers Information


In such a setup using X-Forward-* headers is the general approach to allow Drupal to build absolute links with the correct protocol to avoid the mixed content error.

However, Drupal pages can be built completely with relative links and this is how Drupal is setup out-of-the-box, including core autocomplete fields. So you could review autocomplete routes in contrib/custom code and remove the absolute option to make them relative.


Redirecting

To avoid further commenting, Drupal doesn't redirect, out-of-the-box. Redirecting is not connected to the issue, it only makes it harder to debug. It's impossible to tell from afar which code you might have implemented which is redirecting. It could also be that the redirects are still cached, permanent redirects get cached for weeks, even if you have removed the redirect code.

11
  • Looks very good!!! I will test this this evening... I can't wait
    – Baud
    Feb 16 at 9:31
  • OK, when testing check the phpinfo() output of your Drupal site before and after the change. See the edit.
    – 4uk4
    Feb 16 at 10:00
  • Unfortunately, this is not working (info: header are set in status page)=> I got ERR_TOO_MANY_REDIRECTS for the autocomplete. There is also the X-Forwarded-For which is set to 192.168.1.1, don't know if this is what it should be
    – Baud
    Feb 16 at 18:15
  • This is the client IP, you need this, too. Apache sets this header by default. But what did happen with the two I've suggested? Missing before and present after? Then remove any other hacks, clear all caches, also the browser cache, restart all servers and try again.
    – 4uk4
    Feb 16 at 18:40
  • X-Forwarded-Proto is set to https and X-Forwarded-Port is set to 443 as displayed by phpinfo().
    – Baud
    Feb 16 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.