Mailman 3 und HyperKitty: "django.request Forbidden" 403

18. August 2023

Mit Debian 11 (Bullseye) kam auch die Umstellung von Mailman 2 auf Mailman 3, wobei es wiederum kleinere Problemchen zu lösen galt.

Eines davon war, dass mit Mailman 3.3.3 (Tom Sawyer) in HyperKitty 1.3.4. in den Archiven der importierten Mailinglisten seltsamerweise keine Statistiken angezeigt wurden. Stattdessen kreiste endlos das Rädchen von ajax-loader.gif.

Die Logdateien beispielsweise /var/log/mailman3/web/mailman-web.log gaben keinen wirklichen Aufschluss. Einzig ein django.request Forbidden: mit einem (HTTP/1.1 403) tauchte vereinzelt auf. Aber keine Hinweise im Debug oder im Entwickler-Fenster im Browser, was der Auslöser der Fehlermeldung sein könnte.

Beim Durchschauen des Quelltextes und von vergleichbaren Seiten mit funktionierender Statistik fiel auf, dass im Prinzip für die Statistiken HTML-Bausteine geladen werden. Das Anhängen von top-threads oder top-posters an den Standardlink der Archivseite brachte auch Ergebnisse zu Tage. Das heißt, dass die Frames aufgrund einer fehlgeschlagenen Sicherheitsrichtlinie nicht nachgeladen werden konnten.

Die üblichen Recherchen führten im Zusammenhang mit Django-Projekten und den Schlüsselworten „Django 403 forbidden“ immer wieder zum Thema „403 Forbidden CSRF verification failed“, was aber auch nicht weiter half. Die bei Debian standardmäßig beiliegende Konfigurationsdatei für Nginx mit UWSGI erwies sich schlussendlich als ausreichend.


# This nginx config file is part of the mailman3-web package.
#
# This nginx configuration file is a vhost configuration. Hence, it comes with
# a server name which is set to mailman.example.com. You will have to change it
# properly.
#
# Please also note that Mailman3 is configured to expect the web interface
# at URL subdirectory '/mailman3' per default, but this Nginx configuration
# provides Mailman3 under the root directory of the vhost.
#
# For the Nginx vhost configuration (without '/mailman3' subdomain) to
# work, you will have to edit the URL in 'base-url' at
# '/etc/mailman3/mailman-hyperkitty.cfg' and in 'MAILMAN_ARCHIVER_FROM'
# at '/etc/mailman3/mailman-web.py' accordingly.

upstream mailman3 {
    server unix:/run/mailman3-web/uwsgi.sock fail_timeout=0;
}

server {
    listen 80;
    listen [::]:80;
    server_name mailman.example.com;
    server_tokens off;

    location / {
        uwsgi_pass mailman3;
        include /etc/nginx/uwsgi_params;
    }

    location /mailman3/static {
        alias /var/lib/mailman3/web/static;
    }

    location /mailman3/static/favicon.ico {
        alias /var/lib/mailman3/web/static/postorius/img/favicon.ico;
    }

#    return 301 https://$server_name$request_uri;
    access_log /var/log/nginx/mailman3/access.log combined;
    error_log /var/log/nginx/mailman3/error.log;
}

# Nginx SSL snippet. To enable it, please uncomment and update the server_name and the
# ssl parameters for the certificate.
# Then, remove all location statements from the above configuration and uncomment
# the return 301 statement.
#server {
#    listen 443;
#    listen [::]:443;
#    server_name mailman.example.com;
#    server_tokens off;
#
#    ## Strong SSL Security
#    ## https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html & https://cipherli.st/
#    ssl on;
#    ssl_certificate /etc/letsencrypt/live/mailman.example.com/fullchain.pem;
#    ssl_certificate_key /etc/letsencrypt/live/mailman.example.com/privkey.pem;
#
#    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
#    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#    ssl_prefer_server_ciphers on;
#    ssl_session_cache shared:SSL:10m;
#    ssl_session_timeout 5m;
#
#    location / {
#        uwsgi_pass mailman3;
#        include /etc/nginx/uwsgi_params;
#    }
#
#    location /mailman3/static {
#        alias /var/lib/mailman3/web/static;
#    }
#
#    location /mailman3/static/favicon.ico {
#        alias /var/lib/mailman3/web/static/postorius/img/favicon.ico;
#    }
#
#    access_log /var/log/nginx/mailman3/access.log combined;
#    error_log /var/log/nginx/mailman3/error.log;
#}

Der vorgeschaltete Varnish-Cache war diesmal auch nicht der Störenfried und konnte ausgeschlossen werden.

Auch Spielereien mit diversen proxy_set_header oder uwsgi_pass_header X-CSRFToken; waren überflüssig. uwsgi_pass_request_headers ist eh standardmäßig eingeschalten.

Allen Quellen in /etc/mailman3-web.py zu trauen, brachte ebenso keine Änderung.


CSRF_TRUSTED_ORIGINS = [
         "*"
         ]

Die Definition von internen IP-Adressen verbesserte die Situation ebenfalls nicht.


INTERNAL_IPS = [
    "127.0.0.1",
    "::1",
   ...
]

Das Gleiche bei den zugelassenen Hostnamen:


ALLOWED_HOSTS = [
         "*"
         ]

Und so weiter und so fort. Am Ende stellte sich wie so oft heraus, dass das Problem vor dem Computer sitzt. Zufällig stand irgendwo, dass der Parameter in der /etc/mailman3-web.py DEBUG = True ein Hindernis sein kann. Und siehe da, nachdem DEBUG = False eingestellt und service mailman3-web restart ausgeführt wurde, werden alle Statistiken normal angezeigt.

Stichworte: Debian, Django, Hyperkitty, Mailman3, Nginx, Python3
Kategorien: Linux, Debian

Linuxspicker