I had a drupal installation working fine. I tried to migrate that one on a Docker Container runing behind a nginx reverse proxy. Everything seems fine but i have some .js and .css files that can't load because in drupal they are linked with http. The error is:
Mixed Content: The page at https://proxy.xx.xx/ was loaded
over HTTPS, but requested an insecure stylesheet
http://proxy.xx.xx/sites/default/files/css/css_xE-rWrJf-
fncB6ztZfd2huxqgxu4WO-qwma6Xer30m4.css'. This request has been
blocked; the content must be served over HTTPS.
I have something like 7 of them and i can't find where those files are called in drupal or how to change the http to https.
Best regards.
Alright, so I got to work by adding the following to the Drupal settings.php:
$conf['reverse_proxy'] = TRUE;
$base_url = 'https://whatever-your-domain-is.com';
$conf['reverse_proxy_addresses'] = array('internal_nginx_proxy_ip');
$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
This works for jwilder's nginx-proxy container(s) together with JrCs' letsencrypt companion container. The nginx container is handling the HTTPS/SSL (certificates) and talks HTTP with the Drupal-container internally. The Drupal container only needs to be run with the 3 ENV VARS VIRTUAL_HOST, LETSENCRYPT_HOST, LETSENCRYPT_EMAIL for everything to be set up and work its magic.
Only downside: The Drupal container's apache logs show the internal IP of the nginx proxy. But the nginx logs show the correct client IPs and Drupal apparently gets them right as well, so it's only a minor nuisance for me.
I guess the additions to the settings.php should also be applicable to custom/manual setups.
We found what was wrong. Drupal was communicating with the Nginx proxy without ssl. Some config and it was ok.
Related
We are running Shopware 6 on a Apache HTTP webserver in Docker on our CI. Then Traefik is doing the SSL termination.
Now on a new Shopware 6.4.12.0 setup we have the problem, that the admin interface which is accessed via https://example.com/admin tries to load its resources from http://example.com/admin.
We believe that is because Shopware sees only the HTTP connection and does not know how to construct the right URLs.
APP_URL in the .env is set to https://example.com
Is this a new behavior in 6.4.12.0 ? How can the SSL offloading be configured?
Looks like we simply forgot a .env setting on the new instance
TRUSTED_PROXIES=127.0.0.1,127.0.0.2,172.0.0.0/8
Trying to reverse proxy with https only. All though the ssl & https works with the chosen domain, it is directing to the apache root not the desired reverse proxy server.
So far Ive got the server to force https when http is used. I rewrite www to non www. Ive had reverse proxy work fine when its just http but https goes to the "it works" root file with a green lock.
Any ideas?
So i solved this issue at the last hour. But where i am confused is i solved this by manipulating the config files and using the defualt text. Not by adding my own virtual hosts and injecting code at the bottom like the old days or blogs would suggest. I added proxy rules into the proxy config file. Added cert paths into the ssl config file and that seemed to take over randomly pasting code into http config as it might be sugested elsewhere on the net.
I have scrapyd installed in Ubuntu.
I also have a website with SSL enabled, I need to make request to links like https://IP_HERE:6800/listjobs.json?project=default inside my website.
But it looks like Scrapyd does not work with HTTPS.
Even if I open link in browser it just keeps loading and loading.
But if I make request using http:// instead of https:// it works. But I want it to work with HTTPS.
I thought I need to edit my SSL conf file to work with port 6800. I did but still its not working.
Here is my SSL config file looks like.
<IfModule mod_ssl.c>
<VirtualHost *:443 *:6800>
.... and rest of confguration...
By looking at the source code of scrapyd, it uses a TCPServer from Pythons socketserver module. It is not possible to enable SSL in a Python module via the Apache config file.
What you want to use is a HTTPS-to-HTTP proxy, which wraps up scrapyd's HTTP into an HTTPS protocol. You can use Apache for that, see this tutorial from Digital Ocean or this blog post.
I have 2 servers, one running my Drupal 7 application through Apache on RHEL 6 and another server is running Varnish Cache. Apache is configured to run on custom HTTP port 8080. I want this application to run on 9443 port with SSL with Varnish Caching support.
I have tried Stunnel, but the site appears broken as the css are not being loaded. I have tried Nginx for SSL termination but browsers complain that there are mixed content as Drupal is generating URLs for resources with "http://".
Any help regarding this will be highly appreciated. Thanks a lot.
You problem is that according to drupal you are running http, and therefore will also return http links. which causes your mixed content issue. have you set your base_url to https?
I've set up a host with apache to serve static pages and to use Tomcat to serve my web application (See this question). The static pages are server from
"http://myhost.com"
and the dynamic (tomcat) pages are server from
"http://myhost.com/myapp"
The mod_proxy makes sure the "http://myhost.com/myapp" are forwarded to tomcat server running on "http://myhost.com:8080".
The problem is that now you get the standard Tomcat introduction page on "http://myhost.com/myapp" but if you click on a local link (e.g. 'Status') on the left, it generates an URL
"http://myhost.com/manager/status" while it should generate: "http://myhost.com/myapp/manager/status"
(The same is true for webapps installed under tomcat)
What should be changed in my configuration (apache, tomcat?) to redirect my tomcat links to the right place?
Have you set the ProxyPassReverse setting in your httpd.conf. This will overwrite the HTTP Header an you'll get to the correct request on the side of tomcat.
Your URLs are mapped from:
http://myhost.com/myapp -> http://myhost.com:8080
This means that accessing the above URL will be mapped to the ROOT application in Tomcat. The ROOT application will generate pages that contain links from Tomcat's root context.
In other words, if you go to:
http://myhost.com:8080
you will get a page that contains links to
http://myhost.com:8080/manager/status
This link will work. However when that page is given back to a browser that requested it via Apache, the full URL then looks like: http://myhost.com/manager/status
I assume that you intend to deploy an application called 'myapp' to Tomcat? If that is the case the Tomcat URL for this app will be
http://myhost.com:8080/myapp
Which will also work be mapped correctly when accessed via Apache.
If you absolutely must access Tomcats root application in this way you'll have to rewrite the URLs it outputs in the pages it returns.
I've had the most success with mod_proxy_ajp. It requires mod_proxy, but works over ajp. Using it instead, your conf file looks similar
ProxyPass / ajp://localhost:8009/
See my similar question and also the answer to this question. The only fault in mod_proxy_ajp that I've found is that if I need to restart tomcat I have to force an apache restart too.