Avatare, Site-Logos und Zertifikatsfehler

[markcichy (Mark)]

Hier ist ein Link zu einer der Instanzen:
https://discourse.mobiusnode.io

Sie ist abgeschaltet. X-Forwarded-Proto ist in meinem Server-Block enthalten. Das einzige Element (bzw. die einzigen Elemente), das/die ich – basierend auf den von Ihnen geteilten Links – nicht verwende, ist Folgendes:

# Basisvorlagen, die verwendet werden; können reduziert werden, um weniger Funktionalität pro Container-Vorlage zu enthalten:
# - "templates/cron.template.yml" # Cron ist jetzt im Basis-Image enthalten
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # entfernen - HTTPS wird vom äußeren Nginx behandelt
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Hinzugefügt
# Welche Ports sollen freigegeben werden?
# expose: gesamten Abschnitt auskommentieren

[itsbhanusharma (Bhanu Sharma)]

Ich habe die Site in drei Browsern geladen (Edge, Firefox und Chrome Mobile). Als Anonymer erhalte ich ein völlig legitimes Zertifikat. Wie gehen Sie vor, um dies nachzuvollziehen?

[markcichy (Mark)]

Als Benutzer anmelden. Sobald die Anmeldung erfolgreich war und ich eingeloggt bin, geht alles drunter und drüber, und ich bekomme die zuvor genannten Fehler.

[itsbhanusharma (Bhanu Sharma)]

Ok, ich melde mich gerade als falscher Benutzer über Firefox an.

[itsbhanusharma (Bhanu Sharma)]

Ihre E-Mails erreichen mein Postfach nicht. Ich habe es erneut versucht, aber leider ohne Erfolg. Aktivieren Sie die Konten hier nur manuell?

[markcichy (Mark)]

Nein. Sie sind wahrscheinlich im Junk- oder Spam-Ordner gelandet. Es gab keine Beschwerden von Benutzern in dieser Hinsicht.

[itsbhanusharma (Bhanu Sharma)]

Hier ist die Hölle nicht losgebrochen. Ein mögliches Problem ist, dass Ihre E-Mails immer noch den Link http:// enthalten. Allerdings wurde ich ordnungsgemäß zur HTTPS-Seite weitergeleitet, um mein Konto zu aktivieren, und ich sehe hier keine SSL-bezogenen Fehler.

Also ja, ich bin zu 99 % sicher, dass Ihre force_https-Einstellung nicht aktiviert ist oder etwas bei Ihrer Installation extrem falsch ist, was dies verursacht.

[markcichy (Mark)]

Ich habe eine Weiterleitung in meinem Server-Block, daher ist es egal, welcher Link dort angezeigt wird. Er wird immer auf https umgeleitet.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

Es ist egal, welcher Link dort angezeigt wird.

Da liegst du falsch. Wenn die Erzwingung von HTTPS aktiviert ist, muss Discourse alle Links als HTTPS ausgeben. Jeder einzelne Link, der mit dem Forum zu tun hat, muss über HTTPS geladen werden. Wenn du immer noch seltsame Dinge machst und nicht den vorgeschlagenen Weg befolgst, bist du auf dich allein gestellt. Wir können nicht über die Standardverfahren hinaus helfen, die funktionieren.

[markcichy (Mark)]

Das ergibt für mich wenig Sinn. Wenn wir das logisch aufschlüsseln, mache ich im Wesentlichen genau das, was force-https bewirken soll, nur innerhalb des server-Blocks.

[markcichy (Mark)]

Außerdem funktioniert meine Seite nicht mehr, wenn ich force-https aktiviere, und die Benutzer können sich nicht anmelden.

[itsbhanusharma (Bhanu Sharma)]

force_https ist nicht nur eine Umleitung. Intern macht es mehr als das. Wenn du möchtest, dass deine Probleme behoben werden, wurde bereits eine Lösung angeboten. Wenn du die Lösung ablehnst, kannst du die Sache selbst in die Hand nehmen und neue Wege erkunden.

@markcichy

Außerdem, wenn ich force-https aktiviere, funktioniert meine Website nicht mehr. Und Benutzer können sich nicht authentifizieren.

Das liegt an deinem instabilen Reverse-Proxy. Du musst selbst herausfinden, was falsch läuft, und die Dinge auf die richtige Art und Weise lösen. Wir können keine Unterstützung für deine eigenen Lösungen leisten.

[markcichy (Mark)]

Alle vorgestellten „Lösungen

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

In Discourse 192.168.20.10:8080:80 freilegen.

Die Socket-Vorlage entfernen.

force_https aktivieren.

Profit.

[markcichy (Mark)]

Das hat eine ganze Reihe von Auswirkungen, die über das hinausgehen, was du gerade geschrieben hast, und die ich noch untersuchen muss – wir hätten dort anfangen können.

Unmittelbare Fragen:

1. In der app.yml den Standard-Listening-Port auf 8080 ändern?
2. Was ist mit SSL 443? Soll 443 erhalten bleiben?
3. Die Weiterleitung auf Port 80 aus dem Nginx-Serverblock entfernen?
4. Spielt Punkt 3 eine Rolle, wenn ich nur die proxy_pass-Einstellung auf der internen Seite ändere? Wahrscheinlich nicht? Ich leite ja nur auf 8080 um?
5. Die größte Frage: Warum? Warum sollte es einen Unterschied machen, von Port 80 auf 8080 zu wechseln?
6. Alle anderen Templates aktiv lassen? socketed einfach auskommentieren?

Vielen Dank für deine Hilfe und Geduld.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

In app.yml den Standard-Listening-Port auf 8080 ändern?

Das ist deine Präferenz. Ich habe es als Beispiel geschrieben. Du kannst auch wählen, Port 80 freizugeben.

@markcichy

Was ist mit SSL 443? 443 offenlassen?

Es gibt keinen Vorteil oder Sinn darin, SSL in einem lokalen Netzwerk zu aktivieren.

@markcichy

Die Weiterleitung auf Port 80 aus dem Nginx-Server-Block entfernen?

Das muss vorhanden sein.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

Ist Punkt #3 wichtig, wenn ich nur die proxy_pass auf der internen Seite ändere? Wahrscheinlich nicht? Ich leite nur auf 8080 um?

Genau das passiert. Du leitest alle Anfragen, die von deinem Proxy/Ingress empfangen werden, an einen internen Backend-Server auf Port 8080 (also Discourse) weiter.

@markcichy

Die größte Frage: Warum? Warum sollte es einen Unterschied machen, von 80 auf 8080 zu wechseln?

In Punkt #1 beantwortet: Es war eine persönliche Präferenz. Du kannst gerne den Port verwenden, der dir gefällt.

@markcichy

Alle anderen Vorlagen aktiv lassen? Nur socketed auskommentieren?

Du brauchst auf dem internen Server insbesondere nichts, was mit Sockets oder SSL zu tun hat. SSL sollte ordnungsgemäß am Reverse-Proxy terminiert werden.

Hinweis: Ein Großteil davon basiert auf persönlichen Präferenzen, die sich aus der Bereitstellung für Kunden ergeben.

[markcichy (Mark)]

Okay. Danke für die Kommentare.

Hier ist mein Nginx-Serverblock, falls es von Interesse ist:

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

    server_name discourse.mobiusnode.io;

    location / {
            # http traffic
            proxy_pass http://192.168.86.108;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

    }

`ssl on;`
`ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # verwaltet von Certbot`
`ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # verwaltet von Certbot`

`ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';`
`ssl_protocols TLSv1.2;`
`ssl_prefer_server_ciphers on;`
`ssl_session_cache shared:SSL:10m;`

`add_header Strict-Transport-Security "max-age=63072000;";`
`ssl_stapling on;`
`ssl_stapling_verify on;`

`client_max_body_size 0;`

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # verwaltet von Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # verwaltet von Certbot

}

[markcichy (Mark)]

Das von mir beobachtete Verhalten tritt unter den oben genannten Bedingungen auf.

Der Anfang von app.yml sieht so aus:

## Dies ist die All-in-One, eigenständige Discourse Docker-Container-Vorlage
##
## Nach Änderungen an dieser Datei MUSS Sie neu gebaut werden
## /var/discourse/launcher rebuild app
##
## SEIEN SIE *SEHR* VORSICHTIG BEI DER BEARBEITUNG!
## YAML-DATEIEN SIND SUPER SUPER EMPFINDLICH GEGENÜBER FEHLERN IN LEERZEICHEN ODER AUSRICHTUNG!
## Besuchen Sie http://www.yamllint.com/, um diese Datei bei Bedarf zu validieren

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Kommentieren Sie diese beiden Zeilen aus, wenn Sie Lets Encrypt (https) hinzufügen möchten
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## Welche TCP/IP-Ports soll dieser Container exponieren?
## Wenn Sie Discourse einen Port mit einem anderen Webserver wie Apache oder nginx teilen möchten,
## siehe https://meta.discourse.org/t/17247 für Details
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Setzen Sie db_shared_buffers auf maximal 25 % des gesamten Speichers.
## Wird automatisch vom Bootstrap basierend auf dem erkannten RAM gesetzt, oder Sie können es überschreiben
db_shared_buffers: "1024MB"

## Kann die Sortierleistung verbessern, erhöht jedoch den Speicherverbrauch pro Verbindung
#db_work_mem: "40MB"

## Welche Git-Revision soll dieser Container verwenden? (Standard: tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

Sie verbinden sich mit Port 80 auf dem zweiten nginx, daher geht dieser davon aus, dass Sie eine HTTP-Verbindung und keine HTTPS-Verbindung herstellen.

Suchen Sie nach X-Forwarded-Proto im inneren nginx und ändern Sie proxy_set_header X-Forwarded-Proto $thescheme; in proxy_set_header X-Forwarded-Proto https;

oder leiten Sie Ihren Verkehr über HTTPS weiter: proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

Dieser Teil muss geändert werden.