DW sometimes emits HTTP URL when reverse proxy is HTTPS

[schplurtz]

Hi,

I use traefik as reverse proxy. Traefik handles HTTPS, and communicate with DW over HTTP in a classic setup:

         HTTPS              HTTP          
client --------> traefik ----------> DW 

Since this is the first time I use this docker image, I don't know if this is a DW Librarian or docker issue.

Expected behaviour:

Out of the box, DW should always detect HTTPS and only emit HTTPS URL.

observed behavior:

Sometimes DW emits HTTP URL, mainly redirects after form validation:

• after successfuly filling in the login form
• after hitting the logout button
• In extension manager : admin > extension manager > search and install > search for something then hit the install button
  but the search is OK
• after validating configuration settings
• after saving page. previewing is OK.

how to reproduce

Install a fresh DokuWiki, run the install script, log in.

I suppose it would be the same with any HTTPS to HTTP reverse proxy.
Here is the docker-compose.yaml file if that matters

services:
  dw:
    image: dokuwiki/dokuwiki:stable
    container_name: dw
    environment:
      - PHP_UPLOADLIMIT=128m
      - PHP_MEMORYLIMIT=512m
      - PHP_TIMEZONE=Europe/Paris
    volumes:
      - ./storage/data/:/storage/
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.http.routers.dw.rule=Host(`stable-dw.justone.freewww.info`)
      - traefik.http.routers.dw.entrypoints=websecure
      - traefik.http.routers.dw.tls.certresolver=certificatator
      - traefik.http.services.dw.loadbalancer.server.port=8080

Version info

As given by DW in the admin panel.

Release 2025-05-14a "Librarian"
PHP 8.3.21
Debian GNU/Linux 12 (bookworm)
Linux 6.8.0-1024-raspi
apache2handler
Docker

more info

inside the container, the container IP is 10.14.4.2, reverse proxy's IP is 10.14.4.1

I've managed to capture HTTP traffic between reverse proxy and DW. It seems to me traefik sets all the headers an app may want.

Client request : a POST to install a plugin

POST /start?do=admin&page=extension&tab=search&q=a2s HTTP/1.1
Host: stable-dw.justone.freewww.info
User-Agent: ... Firefox/139.0
Content-Length: 65
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Content-Type: application/x-www-form-urlencoded
Cookie: DokuWiki=hidden; DOKU_PREFS=hidden; DWscrambled=hidden
Dnt: 1
Origin: https://stable-dw.justone.freewww.info
Priority: u=0, i
Referer: https://stable-dw.justone.freewww.info/start?do=admin&page=extension&tab=search&q=
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Sec-Gpc: 1
Te: trailers
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 192.168.255.1
X-Forwarded-Host: stable-dw.justone.freewww.info
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: leela
X-Real-Ip: 192.168.255.1

Server answer, redirect to HTTP

HTTP/1.1 302 Found
Date: Sat, 31 May 2025 06:59:40 GMT
Server: Apache
X-Powered-By: PHP/8.3.21
Vary: Cookie
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: DokuWiki=xxxxx; path=/; HttpOnly; SameSite=Lax
Location: http://stable-dw.justone.freewww.info/start?do=admin&page=extension&tab=search&q=a2s
Content-Length: 0
Content-Type: text/html; charset=UTF-8

[yusuf57rl]

I can confirm the same problem on my setup (Traefik as reverse proxy, Cloudflare Flexible in front, DokuWiki official Docker image). I’ve already tried:

• setting X-Forwarded-Proto and X-Forwarded-Port headers in Traefik
• mounting an Apache conf with SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on
• forcing baseurl + securecookie in conf/local.php

But I still get mixed redirects (HTTP instead of HTTPS) after login/logout or saving settings. So far no combination has solved it.

[splitbrain]

I can not reproduce the issue on my systems running this container behind traefik as well (or I am not looking at the right thing). But I am pretty sure it is related to dokuwiki/dokuwiki#4455

[schplurtz]

or I am not looking at the right thing

Error only occurs when DW performs a redirect. After filling the login form, saving a page, saving settings.

Browsing pages works like a charm.

[schplurtz]

No config apart running the install.php was done. So this is the default config.

Thus there is no proxy thingy configured, be it the old one or the new one. This is just the basic official docker image deployed with traefik as reverse proxy.

Here is the local.php file if that can help.

<?php
/*
 * Dokuwiki's Main Configuration File - Local Settings
 * Auto-generated by config plugin
 * Run for user: ztrulphcs
 * Date: Sun, 01 Jun 2025 15:21:33 +0200
 */

$conf['title'] = 'lewiki';
$conf['lang'] = 'fr';
$conf['license'] = 'cc-by-sa';
$conf['useacl'] = 1;
$conf['superuser'] = '@admin';
$conf['disableactions'] = 'register';

According to documentation, the trustedproxies default value is '::1', 'fe80::/10', '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' which should be ok since, as mentionned, internal docker IP network is 10.14.4.0/24.

[schplurtz]

Manually adding the old setting $conf['trustedproxy']='^.'; does indeed solve the problem. This is weird.

But I don't feel safe with that, because in inc/Ip.php one can read this warning.

     *
     * The 'trustedproxy' setting must not allow any IP, otherwise the X-Forwarded-For
     * may be spoofed by the client.
     *

So I'm puzzled and it seems I am left with some strange choice:

• having DW safely redirect to HTTP, which breaks navigation
• using the old proxy setting, that allows smooth navigation but that is unsafe.

[splitbrain]

Setting the old setting is fine as long as your wiki is actually behind a proxy. It will always set the X-Forwarded-For header itself.

[foozzi]

@schplurtz Hi, did you manage to resolve the problem? I have the same one.
I use Nginx as a proxy.

[Powerkrieger]

Us aswell. Getting the Http site warning after login is confusing and probably deters users. Could anyone clarify more deeply what is happening and why or why not it would be safe to set the option mentioned above?

Is it $conf['trustedproxy']='^.'; or $conf['trustedproxy']='::1', 'fe80::/10', '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' ?

[schplurtz]

Is it $conf['trustedproxy']='^.'; or $conf['trustedproxy']='::1', 'fe80::/10', '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' ?

@Powerkrieger. It cannot be $conf['trustedproxy']='::1', 'fe80::/10', '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' for 2 reasons:

1. this is not a valid PHP syntax,
2. trustedproxy uses a regexp, not a list of CIDR IP. Note there exist a newer setting that uses a list of CIDR. It has the same purpose and a very similar name, but sadly, no effect in this redirection issue. Only the plain old trustedproxy can be used as a workaround.

You could probably use this:

$conf['trustedproxy']='^(::1|[fF][eE]80:|127\.|10\.|192\.168\.|172\.((1[6-9])|(2[0-9])|(3[0-1]))\.)';

Now, $conf['trustedproxy']='^.'; is an expression that means “Trust any machine that sends the X-Forwarded-For header.”. It was a quick way for me to be sure this would work. Also I wanted to use something easy to understand and non ambiguous for DW devs. However, It should only be used when there really is a reverse proxy. If there is no actual reverse proxy, using $conf['trustedproxy']='^.'; is a very bad idea. Probably some security concern as it would allow anyone to spoof their IP.

[schplurtz]

@schplurtz Hi, did you manage to resolve the problem? I have the same one. I use Nginx as a proxy.

@foozzi Hi. The workaround is to add this to file conf/local.php.

$conf['trustedproxy']='^.';

With this, it works with traefik as a reverse proxy. Should work also for nginx provided nginx sets the X-Forwarded-For and X-Forwarded-proto headers. Can't be sure though...