Da Discourse nicht Apache verwendet, wie kann man z. B. eine Testumgebung (Digital Ocean Droplet mit Discourse Docker) passwortgeschützt machen, wie man es mit .htaccess (Apache) tun würde?
Es ist kein Apache vorhanden, aber NGINX läuft im Discourse-Container. Dieser Beitrag könnte helfen:
3 „Gefällt mir“
Perfekt, danke @david 
1 „Gefällt mir“
Ich habe es gerade hinzugefügt, aber jetzt muss für jedes Bild von https://cdn-uploads.example.com und https://cdn-origin.example.com das Authentifizierungspasswort eingegeben werden. Gibt es eine Möglichkeit, nur https://discourse.example.com zu schützen?
Andernfalls bekomme ich jetzt Folgendes:
Ich bin mir nicht ganz sicher, wie das genau erreicht werden kann, aber vielleicht meldet sich jemand anderes mit ein paar Ideen. Mit ein paar Anpassungen in der nginx-Konfiguration sollte das möglich sein.
Als Workaround und da es sich um einen Staging-Server handelt, könntest du das CDN einfach deaktivieren? Wenn du dieselbe Domain für Assets verwendest, werden sie automatisch mit dem Authentifizierungs-Header gesendet, sodass du das Authentifizierungspasswort nicht erneut eingeben musst.
1 „Gefällt mir“
Ja, sicher, wenn dies der empfohlene Ansatz für eine Staging-Umgebung ist, bei der Sie S3-Buckets für Backups und Uploads sowie CloudFront als CDN für Uploads und als Origin für die Produktion verwenden.
Muss man das für eine Staging-Umgebung wirklich alles haben?
Diese NGINX-Änderung sollte S3-Uploads oder das S3-CDN definitiv nicht beeinflussen. NGINX ist dort überhaupt nicht beteiligt. Ich hatte angenommen, dass du lokale Uploads mit einem CDN verwendest?
Der ideale Zustand besteht darin, die Staging-Site identisch zur Production-Site zu konfigurieren.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_ACCESS_KEY_ID: XXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_SECRET_ACCESS_KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DISCOURSE_S3_CDN_URL: https://cdn-uploads.example.com
DISCOURSE_S3_BUCKET: example-uploads
DISCOURSE_S3_BACKUP_BUCKET: example-backup
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_CDN_URL: https://cdn-origin.example.com
Die Hauptdomäne für die Staging-Umgebung ist derzeit https://staging.example.com.
Trotzdem werde ich bei jedem einzelnen Request von cdn-origin zur Authentifizierung aufgefordert, wenn ich mit dem vorgeschlagenen Code auf https://staging.example.com zugreife.
Update für alle, die auf das gleiche Problem stoßen:
Wir mussten die Authorization-Header in CloudFront für cdn-origin freischalten.
Es scheint, als wäre ich bei cdn-uploads nicht zur Authentifizierung aufgefordert worden.
Funktioniert jetzt.
2 „Gefällt mir“
Ich habe die Anmeldung auf der Staging-Umgebung aktiviert. Sie können dies über eine Umgebungsvariable in der app.yml einrichten, damit die Einstellung dauerhaft gespeichert wird.
Nicht gut genug, wenn Google oder sonst jemand die Seite findet. Wie auch immer, es funktioniert jetzt.
1 „Gefällt mir“
Sie werden die Seite sehen, aber keinen Inhalt einsehen können. Richtig?
In unserem Fall müssen wir auch nachvollziehen können, wie die Seite auf anonyme Benutzer reagiert. Also gut, es funktioniert jetzt mit basic_auth.
2 „Gefällt mir“
Na, du bringst mich zum Umdenken, wie ich das mache!
Hallo @Terrapop,
Hier ist eine Idee für dich, so machen wir es auch.
Wenn du deine Staging-Umgebung hinter einem Apache2 (oder nginx) als Reverse-Proxy betreibst, kannst du Zugriffsregeln im Reverse-Proxy einrichten, ähnlich wie du es mit .htaccess kennst.
Es gibt zahlreiche Vorteile, Discourse hinter einem Reverse-Proxy zu betreiben, und die einfache Zugriffskontrolle ist nur einer davon.
Ich hoffe, das hilft dir weiter.
Gibt es eine foolproof-Anleitung für Nginx? Wir hosten über DigitalOcean mittels Droplet und Docker.
Hallo @Terrapop,
Es gibt zahlreiche hervorragende Tutorials auf Meta, wie man Discourse in einer „Two-Container“-Konfiguration hinter einem Reverse-Proxy einrichtet.
Du kannst auf Meta danach suchen:
two container reverse proxy
Ich hoffe, das hilft weiter.
Hinweis: Für einfaches Staging richten viele Leute keine „Two-Container“-Konfiguration ein und tun dies nur in der Produktion. Wenn du jedoch exakt wie in der Produktion stagen möchtest, ist „Two-Container“ definitiv eine gute Wahl. Du brauchst „Two-Container“ jedoch nicht, um eine Web-App hinter einem Reverse-Proxy zu betreiben. Ich betreibe regelmäßig ROR- und Docker-Web-Apps hinter einem Reverse-Proxy, sowohl in der Produktion als auch in der Entwicklung.
3 „Gefällt mir“
Hallo. Ich möchte nur wissen, wie man die Autorisierungs-Header in CloudFront korrekt freigegeben (whitelisted). Ich habe “auth_basic” in app.yml wie oben angegeben hinzugefügt. Der Passwortschutz funktioniert beim Surfen über den Desktop, aber beim Surfen über das Mobile erhalte ich dies (nach Eingabe von Benutzername und Passwort):
In meiner “cdn-origin” habe ich folgendes:
Richtlinie “whitelist-authorization-headers”:
Ich bin mit CloudFront noch recht neu und habe vielleicht nur etwas Offensichtliches (für die Mobile-Konfiguration) übersehen.