i have installed wordpress and i've set SSL (LetsEncrypt).
It works fine since few months.
Now i want to add Varnish to speed up site and i have one issue.
My config is:
MyPage.com (443) -> Varnish (80) -> MyPage (8080) no https.
When i open page, everything is OK
besides address to static files.
All URL's to CSS, JS, Images are served as HTTP, NOT HTTPS.
That is because in the end page is served by Apache without SSL.
Do you know how to change address to static files, that they will be served as HTTPS (https://MyPage.com/my.js instead of http://MyPage.com/my.js)?
Wordpress save the links absolutly in the database.
Soloution 1:
You edit all entries in the Database
Soloution 2:
Simple use this Plugin to write all url´s in the database from http to https:
https://de.wordpress.org/plugins/really-simple-ssl/
You might need to make sure the X-Forwarded-Proto header is set and passed all the way back through Varnish to the backend.
Assuming you have Apache:443 -> Varnish:80 -> Backend:8080
Then in the Apache config that is handling the https add the following to the VirtualHost
RequestHeader set X-Forwarded-Proto "https"
Varnish should forward this by default, unless you have done anything custom to the config that might prevent it.
This header should then be respected and used to set the protocol on the urls for assets.
Related
I use wicket 8.10, it is installed on tomcat and proxied by nginx. SSL certificates configured in nginx config. Also Nginx forwards all HTTP requests to HTTPS.
The problem is following:
When I submit any form wicket returns response headers where the Location tag contains url with HTTP protocol.
Why it is important:
The last chrome update makes browser show alert when Location contains HTTP protocol on page opened by HTTPS. Before that, nginx quietly redirected the request, but now user see alert page from browser (similar to when certificate is invalid or absence).
The problem here is that your Wicket application does not know that it is behind a proxy.
There are two solutions:
use XForwardedRequestWrapperFactory
It will wrap the Tomcat's HttpServletRequest with one that reads X-Forwarded-*** request headers.
Just make sure that Nginx exports X-Forwarded-Proto request header
use HttpsMapper
Just overwrite protected Scheme getDesiredSchemeFor(Class<? extends IRequestablePage> pageClass) to return Scheme.HTTPS in PRODUCTION mode and Scheme.HTTP in DEVELOPMENT mode (I assume you don't use Nginx proxy while developing)
The simplest solution I have found is to use the nginx directive:
proxy_redirect http://example.com https://example.com;
It changes location header from http://example.com/any/path to https://example.com/any/path
Current Scenario
I am hosting a wordpress website on a ECS instance which runs wordpress in a docker container
My wordpress is working fine but i want to change HTTP to HTTPS
What i dont want to use
1) ELB
2) Anything cost ineffective
What i tried
I tried using cloud front and setting ec2-52-64-xxx-xxx.ap-southeast-2.compute.amazonaws.com as origin domain and origin id
I also set it to redirect HTTP to HTTPS
Current CloudFront behaviour
What happens is when i goto the cloudfront link it redirects me to ec2-52-64-xxx-xxx.ap-southeast-2.compute.amazonaws.com (HTTP) instead of using the cloudfront link
Desired CloudFront behaviour
It should use the HTTPS cloudfront URL to use my wordpress website by redirecting any traffic from my origin from HTTP to HTTPS
Current Server configs
1) I don't have any SSL/TLS certificate installed in my ECS instance
2) My .htaccess file has default values (not sure if i even should update it or cloudfront will work without any changes to .htaccess)
3) Wordpress is not installed so the database does not have any values which might be causing a redirect ( I deleted the database to test if that might be causing the inconsistency)
I am really new to AWS,There might be a better way to achieve HTTP to HTTPS redirect i think any sugggestions/help is highly appreciated thanks :)
we have activated HTTP Strict Transport Security in production. It works well. But now, when wanting to use a subdomain to develop, the website is automatically redirected to https:
https://dev.tokeeen.com/app_dev.php/my-habits
Event if the host is set to 127.0.0.1
127.0.0.1 dev.tokeeen.com
Is there something to avoid this behavior? Of course I don't want to force the host for the main domain.
You are currently setting this on your main site:
Strict-Transport-Security max-age=63072000; includeSubDomain
If you change this to remove the includeSubDomain bit then it will only apply to your top level domain and not the dev sub domain:
Strict-Transport-Security max-age=63072000;
You then need to visit your production site to load this header and overwrite the existing one in your browser’s cache.
However this is less secure (for example someone could set up www.tokeeen.com and pretend to be your site with a bit of DNS manipulation for example).
But to be honest you should just use https on you’re dev site. The Internet is moving towards HTTPS and many new features do not work under plain HTTP. Additionally what you are developing is not similar to your production site so if you include http:// links instead of https:// for example you’ll suddenly see this failing when you release to production.
You look to use LetsEncrypt on your site so the cert is free. Do yourself a favour and just get another free one for your dev subdomain.
You have to get yourself a wildcard certificate as the ssl certificate is only for that domain. That's the whole point of having a secure site.
I'm not sure what server system you are using but in case you don't want to use wildcards and are ok with less secure, you can bind the other domains to
port 80 with the binding type http`
I've got an apache running wordpress on port 90. I've put a varnish cache in front of it and am running varnish on port 80.
I'm using the 4.0 vcl from here: https://github.com/nicolargo/varnish-nginx-wordpress/blob/master/varnish/varnish4-wordpress
When I request my site on :80 I get 301 redirected to :90 ... Surely that's not the point of varnish? How do I avoid this and stay on :80??
I'm a complete newbie to varnish / vcl so I unfortunately have no idea what to look for. I'm sure it's in the VCL though :)
Related post (but not answer on here either): Why is Varnish redirecting as 301?
It is surely not in VCL. However, do note that it's much better to start building from the provided default.vcl, adding bits by bits, to understand how it works.
As for why it doesn't work and ways to fix it.
Different ports (duh).
Option #1. Tell your PHP what the real port is.
Perhaps, the most easy fix would be to edit wp-config.php and tell the Wordpress where the request really came from. Add at the top of the file right after <?php:
$_SERVER['SERVER_PORT'] = 80;
Option #2. Just use the same ports.
You can actually use same port number(!) in both Varnish and Apache. Simply bind Varnish and Apache onto different interfaces, but same port numbers. To a Linux machine those are different ports, and there is no issue using same port number.
So Apache will have:
Listen 127.0.0.1:80
Varnish will have in the VCL:
backend default {
.host = "127.0.0.1";
.port = "80";
}
Option #3. Don't use Apache. Nginx to the rescue.
A not so easy fix perhaps would be switching to Nginx which can easily circumvent the "port in redirection" problem via simply one line of configuration:
port_in_redirect off;
Wordpress base URLs.
If the Wordpress site URL (in wp-admin) is set to include port number, then naturally that's where it will redirect you. No port number should be present in Wordpress site URL.
Bonus Tip: Fix Wordpress Jetpack in Varnish.
Having problems accessing the admin over https when it's setup behind CloudFront Flexible SSL.
The admin works fine when accessing over http, but as soon as I change to secure https it ends up in a redirect loop.
I'm adding the following line to wp-config.php to force SSL in the admin.
define('FORCE_SSL_ADMIN', true);
This is due to the fact that CloudFlare's Flexible SSL operates as a reverse proxy and connects to the WordPress installation via http. Wordpress thinks you're connecting via http and does a redirect to the https resource. The browser requests the https resource from CloudFlare and CloudFlare again requests the resource over http from the WordPress server, resulting in another redirect.
Fortunately there's a solution. CloudFlare sends an http header X-FORWARDED-PROTO that is the protocol used in the connection from the browser to the CloudFlare server. We can use this to tell WordPress that even though the request is happening over http, the link to the browser is over https.
In the wp-config.php file add the following line:
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';
It's also crucial that the above line comes before the following line:
require_once(ABSPATH . 'wp-settings.php');
After making that modification the redirect loop will stop and you'll be able to use the admin again.
This ultimately applies to all reverse proxy servers, not just CloudFlare.
In my case we getting this problem because I configure CloudFront origin incorrect.
cloudfront-> origin -> Origin Protocol Policy -> Match Viewer
after this setting my website working fine
in my case, another source of problems was (I know sounds silly) the DefaultRootObject.
I had this error on my CloudFront and WordPress and was the issue of my Too Many Redirects nightmare. I'm posting that because someone falls into the same stupid error like me.
Cheers