I'm running dokuwiki on apache, not exposed directly to external requests. Nginx is used as a reverse proxy and also adds SSL. Since the network between nginx and apache is considered secure (never leaves the host), no SSL is applied on apache side. Every request to apache is made over plain HTTP.
When saving a page after an edit or when hitting cancel the user is currently redirected to HTTP from HTTPS. The problem here is to edit the page you must be authenticated and so I configured nginx to force HTTPS for the authentication:
location /dokuwiki {
# redirect to https for login and admin
if ($args ~* do=(log|admin|profile)) {
rewrite ^
https://$host$request_uri? redirect;
}
proxy_pass
http://localhost:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
when authenticated a user should stay on HTTPS, but HTTPS cannot be enforced for every page, since anonymous access can happen via HTTP, nothing wrong with that. And anyway one less redirect is a good thing.
If I understood well the problem begins in the inc/actions.php
function act_redirect_execute($opts){
$go = wl($opts['id'],'',true);
if(isset($opts['fragment'])) $go .= '#'.$opts['fragment'];
//show it
send_redirect($go);
}
the third argument to wl is true, so the redirect is absolute and wl() will use DOKU_URL as a starting point. I don't set DOKU_URL, so dokuwiki is autodetecting.
The getBaseURL function works as expected in building the URL except for the protocol used, which is http and not https. Https is used only if is_ssl returns true. I think the problem is here.
is_ssl() should check for X-Forwarded-Proto header (and likely also for Front-End-Https) to evaluate if ssl should be used or not. Another solution can be doing the redirect relative instead of absolute in act_redirect_execute, but I have no idea if this can have some unwanted collateral effect.
I think this is a, quite mild, security issue. An authenticated user might be dropped to http, depending on the server config.