[pmwiki-users] Https and ShortUrl

[Petko Yotov]

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, kirpi at kirpi.it 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.