See https://www.dokuwiki.org/plugin:forcessllogin, doesn't seem to reflect SSL access in URL, i.e. dokuwiki's access denied page won't be opened via https protocol which makes debugging and assuring that you're securely logging in difficult.

Using Apache's mod_rewrite, DokuWiki logins can be forced to use HTTPS, thus preventing clear text passwords on the wire.

You may want to read up on general rewriting first.

Redirection to a secured connection which is restricted to a certain set of pages (e.g. login pages) requires their recognition based on the URL. Some pages (e.g. “access denied” pages which might be included only in newer versions, e.g. 2014-05-05 “Ponder Stibbons” <ref>https://www.dokuwiki.org/plugin:ondeniedlogin</ref>) don't include such a mark and cannot be distungished from the rest of URLs (which one might want to be accessed without a secure connection in order to save server resources).

The rest of the paragraph only handles requests with a ?do=login GET query which doesn't cover at least “access denied” pages! Research about a redirection rule for all authentification requests over HTTP is necessary.

The following assumes you already set up HTTPS support for your wiki, making it available via HTTP and HTTPS on the same address. For performance reasons only the login and profile updates should be forced to HTTPS while all “normal” wiki actions will continue to work on HTTP.

Since you need to have cookies set up via HTTPS to work on HTTP as well, you need to disable the securecookie option first. Then proceed to set up the redirection in your .htaccess:

# Switch to secure on login, profile and admin actions
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{QUERY_STRING} do=(log|profile|admin)
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,QSA,L,NE]

# Change back to non-secure on show action
RewriteCond %{HTTPS} on
RewriteCond %{QUERY_STRING} !do=(log|profile|admin)
RewriteCond %{REQUEST_METHOD} GET
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

You may want to change ${HTTP_HOST} to ${SERVER_NAME}, where server name matches the hostname in your SSL certificate.

Notes:

• the above switches back to non-SSL on the show action only. This means switchback might not occur immediately after login, but ensures there will be no “mixed content” warnings during the SSL operation.

• if you have other rewrite rules, such as those used in general rewriting, place these rules before the others.

• if your DokuWiki's installation directory isn't the root directory (something like http://example.com/wiki/), you have to add this extra path to the lines 5 and 11 of the above snippet, which will thus be something like: RewriteRule ^(.*) http://%{HTTP_HOST}/wiki/$1 [R,QSA,L]

Please note: You need to disable the “securecookie” in conf/dokuwiki.php in order for the above code to work. Otherwise your logins will not successfully register. This is because with securecookie enabled, the session cookie created during the HTTPS login can't be sent over HTTP and the session is lost.

This setup is also possible in nginx but with a minor tweak to your fastcgi_params.

First, you need to have separate server instances, for http and https each, to keep things clean (and for rewrite not to get confused and get trapped in redir loops). This can look like this. Each instance has it's own rewrite rule to switch from http and https.

# Tested with nginx 0.8.5
# In http context of your nginx configuration
map $scheme $php_https { default off; https on; }

    server {
	server_name wiki.host.org
	root /path/to/dokuwiki;
	index doku.php;
	listen 80;
	#Enforce https for logins, admin
	if ($args ~* do=(log|admin|profile)) {
		rewrite ^ https://$host$request_uri? redirect;
	}
	include dokuwiki.conf;
    }

    server {
	server_name wiki.host.org;
	root /path/to/dokuwiki;
	index doku.php;
	listen 443 ssl;
	keepalive_requests    10;
	keepalive_timeout     60 60;
	ssl_certificate      /etc/ssl/certs/ssl-cert-snakeoil.pem;
	ssl_certificate_key  /etc/ssl/private/ssl-cert-snakeoil.key;
	#switch back to plain http for normal view

	if ($args ~* (do=show|^$)){
		rewrite ^ http://$host$request_uri? redirect;
	}
	include dokuwiki.conf;
    }

In dokuwiki.conf (same path as your nginx.conf) you can use the snippet from nginx wiki, but you need to add

fastcgi_param HTTPS $php_https;

to your your fastcgi_params. This parameter and the map directive in the beginning are required because Dokuwiki checks for $_SERVER['HTTPS'] to work.

Like with apache, you need to disable securecookie in your conf/dokuwiki.php.

Isn't general rewriting a requirement to get rewriting for login working so that the sentence should be clearer? I myself didn't get to that point so far, but as far as I'm concerned the managing of some config settings like basedir, and setting the appropriate $conf['userewrite'] value (see also Discussion) seems crucial — krichter 2014-06-02 01:11

Are these instructions up to date for 2014-05-05 “Ponder Stibbons”? If yes, is there a template to include an overview for tested versions (with indication whether it's working for them or not, like for plugins) - facilitates the research enormously. If no, is there someone who has an idea (with redirection to HTTPS (first section for .htaccess I get it working partially - it's more randomly actually - and with both section I get an endless redirection warning of firefox (tried about 20 to 30 combinations with hints from general rewriting and gave up…

I have created the solution to the “access denied” pages that enables rewrite rules to redirect the user to an SSL login page. This fix was an edit to the source code that redirects the user to the same page with the ‘do=login’ query string this enables the rewrite rules to take effect and redirect to an SSL login page, once the user logs in they will be presented with the page they tried to access. This fix is on my websites ‘bug and feature tracker’ as a patch file. Jon, No Fuss Computing.