In my setup it is very similar to running behind Amazon load balancer except that in case I am running squid as a reverse proxy.
The goal is to have the entire site be running HTTPS and actually redirect any HTTP requests to HTTPS.
What needs to happen is that Magento needs to respond to any requests with https and NOT send any redirects as the reverse proxy handles all that.
I was able to get the front end to mostly behave itself but the backend (admin) just will not cooperate. I have to force the backend to communicate over http. Attempts to have it talk properly results in redirect loops.
Anyway the fix the front end, I leave all Magento settings stock but declare a "setenv HTTPS on" .
in .htaccess I cannot set a 301 redirect at the proxy nor can i set add a header :Content-Security-Policy "upgrade-insecure-requests;" in apache2.
in short hand here is the basic network configuration
you -> firewall ---443 -----squid proxy -----80 -----apache ----> magento
The squid proxy also does RFC1918 address translation.
Has anyone else encountered this situation? I would like to have the entire site talk HTTPS. It is ridiculous to have just the checkout talk HTTPS. There is a push from many places to have every web server on the internet be HTTPS. Google.com forces https and it is just a search engine.
My basic problems are this:
1 - I cannot force HTTPS at the proxy as that breaks the backend communications entirely and I cannot get it.
2 - The main page on the frontend can be contacted via HTTP but as soon as I click on anything it switches over to HTTPS without issue. I want the main page to redirect to HTTPS using a squid rule.
What does the admin side want to behave so badly (sends redirects) when it sees that the env variable "HTTPS" is set to "on"?
Magento 1 does not have this problem.
Anyone have any ideas?
Solved! Go to Solution.
Why do you use squid?
My current config:
you -> varnish -> m2
I also need to move all site to https and choose next config.
you -> nginx (ssl endpoint) -> varnish -> m2
Check more details here - https://medium.com/magebit/magento-2-full-ssl-with-varnish-d2cfed3d7df
Best regards, Alex
I found out what my problem was.
It was a combination of bookmarks that had a URL without the trailing slash, a corrupt cache in browsers, and a corrupt magento cache.
In the end, my site is now 100% HTTPS, all requests are being forced to HTTPS, backend works without issue, and all is right with the world again.
To answer your question regarding squid. I rely on squid to do a great many things. I see no point in changing reverse proxy/web accelerator. One of the things that it does is provide a means to have a single certificate handle all of the sites I host. The other option is to have separate certs on every app/webserver I have. The admin of those certs would be a nightmare. Troubleshooting on my lan would be impossible if HTTPS were sent to all my webservers.
This was an experiment to see how Magento stacks up to wordpress/woo-commerce. So far I think Magento is the winner.
Anyway, the bottom line is this if someone is going to move to HTTPS from HTTP behind a load balancer/proxy.
1 - declare "setenv HTTPS on" in the magento root .htaccess file
2 - make sure the browser's cache is cleared.
3 - turn off auth key in url in magento
4 - base and secure urls remain unchanged from installed defaults
5 - use secure urls in storefront = no
6 - use secure URLs for admin = yes
7 offloader header defined as HTTP_SSL_OFFLOADED
8 - use web server rewrites = no
9 - add secret keys to URL = no (unsure if this has any impact or not)
10 add header to vhost config in apache.
> Header add Content-Security-Policy "upgrade-insecure-requests;"
11 - force https by adding a ACL to squid.
12 - clear magento cache with "php bin/magento cache:clean" and "php bin/magento indexer:reindex"
13 - clear apache cache with "/etc/init.d/apache2 restart"
14 - clear squid cache.
Here is my config
you -> fwbuilder/squid -> apache/MG2/WP/etc.
internal ip addr are RFC1918 addrs.
it has been my setup for years. It has proven reliable.