Sometimes the Apache rewrite engine is a pain to use and debug.
You can easily do the redirection from within config.php, near the top
of it:
if($UrlScheme == 'http')
Redirect($pagename,
"https://www.yourwiki.net".$_SERVER['REQUEST_URI']);
I'd use "www.yourwiki.net" instead of $_SERVER["HTTP_HOST"] in order to
redirect people who went to "yourwiki.net" to the host that has "www."
in front (better for search engines to have a single hostname).
Depending on your audience it may not be suitable to redirect everyone
to the HTTPS website.
I've recently worked with a large public organization with thousands of
users that may use a wiki both with their own devices, and with the
computers of the company that only have MSIE 6 to 8 as a web browser.
Windows XP and other older operating systems do not support the new free
"Let's Encrypt" certificates and users of these cannot open the secure
wiki.
What I ended up doing is use JavaScript to perform the redirect, only
for the browsers that are able to open the HTTPS connexion.
In your document root, place such a file named redirect-to-https.js:
// Written by Petko Yotov (c) 2016 www.pmwiki.org/petko
var currenthref = window.location.href + '';
var newhref = currenthref.replace(/^http:/i, 'https:');
if(currenthref != newhref) window.location.href = newhref;
In your config.php, place these lines instead of the ones I gave
earlier:
if ($UrlScheme == 'http') $HTMLHeaderFmt['redirect-to-https'] =
'<script type="text/javascript"
src="https://www.yourwiki.net/redirect-to-https.js";></script>';
The JS file instructs the browser to replace the current unsafe
connexion with the secure one.
The config.php code only includes the JS file in the HTML source if the
protocol is "http".
If a browser opens an insecure page, it will try to load the JS file. If
it is able to load it, that means it is able open the secure connexion
and it gets immediately redirected.
If an older browser cannot open the secure connexion, it will be unable
to load the JS file so it will ignore it and display the (insecure)
page, as PmWiki will happily serve it. This is a lesser problem than a
large group of the intended audience being unable to reach the wiki.
In case you have a modified $ScriptUrl variable, use $UrlScheme in it
instead of "http" or "https":
$ScriptUrl = "$UrlScheme://www.yourwiki.net/";
Petko
On 2017-02-14 16:21, [email protected] wrote:
It seems that there is an ongoing trend towards having our whole
websites reachable only through the https protocol.[1][2]
Thus, I am now in the (not so straightforward) process of switching
from http to https.
As far as I can understand, the whole process could be split in two
parts:
1) Enabling https for the domain. - After this step the whole the
website is reachable through both ports 80 (HTTP) and 443 (HTTPS);
2) Forcing (all) the connections to use https, as opposed to plain
http[3]
In my case, I am on a cheap shared hosting, with limited flexibility.
Nonetheless step 1 has been completed and I am now able to reach my
website with both http and https.
The second step seems now the trickiest.
I set these lines towards the top of my root .htaccess file,
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
which seem[4] to take care of the thing. And indeed, as far as I can
see, all the http connections result now as https.
Nonetheless I have some issues, one of which is related to the
ShortUrl[5] recipe.
I have
RedirectMatch ^/s(.*)$ /S/$1
just above the "RewriteEngine On" line, as well as
$ShortUrlPrefix = 'https://example.com/s';
in config.it, but I keep on getting "This site can’t be reached" from
the browser whenever I type a short url in.
Alternatively, I get a message from Pmwiki: ShortUrl error: can't read
code map.
And the url appears to change into something like
https://www.example.com/S/x (which did not happen before).
Reading on the web, it seems that many different things might create
issues in the http/https switch, from cookies to more esoteric
subtleties.
Does anybody know where the issue might be in this very case, please?
Thanks!
Luigi
--------
[1] "You should always protect all of your websites with HTTPS, even
if they don’t handle sensitive communications. Aside from providing
critical security and data integrity for both your websites and your
users' personal information, HTTPS is a requirement for many new
browser features..."
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
[2] "There’s pretty broad agreement that HTTPS is the way forward for
the web..."
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[3] I am adopting an .htaccess approach as opposed to suggestions
found at http://www.pmwiki.org/wiki/Cookbook/SwitchToSSLMode as I
would like to switch all the website to https:
[4]
http://stackoverflow.com/questions/26620670/apache-httpx-forwarded-proto-in-htaccess-is-causing-redirect-loop-in-dev-envir
[5] http://www.pmwiki.org/wiki/Cookbook/Bloge-ShortUrl running very
well since many years.
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
