Avatar Proxy- und CDN-Hotlink-Schutz

Meine Discourse-Website ist bildlastig. Aufgrund der vielen Bilder verwende ich eine S3/CDN-Kombination zum Speichern und Ausliefern von Bildern. Innerhalb des CDN verwende ich verschiedene Maßnahmen, um Image Hijacking zu verhindern. Eine der Maßnahmen besteht darin, jeglichen direkten Zugriff auf Bilder zu unterbinden und nur den Zugriff von einer definierten Hostnamenliste zu gestatten.

Discourse funktioniert mit dieser Einrichtung, außer bei Avataren. Avatare funktionieren nicht mehr, wenn der Hotlinking-Schutz aktiviert ist.

Der Grund dafür ist, dass Discourse ein Proxy-Setup für Avatare verwendet. Das HTML verwendet einen Proxy-Link für Avatare. Die Linkstruktur lautet https://discourse.forum/user_avatar/discourse.forums/username/24/616_2.png.
Sobald der Proxy aufgelöst ist, fordert der Browser den direkten Zugriff auf die Bilddatei an.

Mein CDN verhindert den direkten Zugriff mit einer 403, wenn diese direkte Anfrage gestellt wird. Und alle benutzerdefinierten Avatare werden zu Silhouetten.

Welche Optionen haben wir, um den Proxy zu entfernen?
Können wir den Avatar in eine Standard-Bilddateistruktur ändern?

Können Sie Ihre Discourse-IP-Adresse nicht auf die Whitelist setzen?

Der direkte Zugriff-Link-Aufruf kommt von der IP-Adresse des Benutzers. Der Server löst die Informationen auf, aber der lokale Browser führt den Aufruf durch.

Ich bin mir nicht sicher, ob das so funktioniert. Je nach Ihrer Konfiguration leitet der Proxy tatsächlich weiter oder das CDN kommt zuerst. Können Sie näher erläutern, wie dies eingerichtet ist?

Ich hasse vage Fragen. Was haben Sie sich gedacht, als Sie nach “dies” gefragt haben?

Hier sind meine aktuellen Einstellungen:

Discourse-Einrichtung:

  • Standardmäßige Einzelcontainer-Installation
  • Als Subdomain eingerichtet: forums.domain.tld
  • Standardmäßige S3-Einrichtung für Uploads
  • Uploads werden auf S3 gespeichert

S3-Einrichtung:

  • Digital Ocean S3 Bucket
  • Bucket für externen Zugriff aktiviert
  • Keine weiteren Sicherheitsebenen oder Berechtigungen

CDN-Einrichtung:

  • Bunny CDN
  • Zulässige Referrer eingerichtet: domain.tld und *.domain.tld
  • Der Schalter, der den Avatarzugriff beendete, war “Block Direct URL File Access” (Direkten URL-Dateizugriff blockieren).

Wenn dies aktiviert ist, erhalten alle Avatare einen 403-Fehler. Wenn dies deaktiviert ist, werden Avatare angezeigt.

Nicht-Avatar-Bilder:

  • URL in Discourse: https://cdn.domain.tld/optimized/3X/3/1/filename_#_size.jpeg

Avatar-Bilder:

  • URL in Discourse: https://forums.domain.tld/user_avatar/forums.domain.tld/mazzini/48/776_2.png

Ein früherer Beitrag, Wie werden Avatare gespeichert und abgerufen?, gibt an, dass Discourse einen Proxy für Avatare verwendet. Daher ist die URL-Struktur für Avatare keine Standard-Bild-URL-Struktur.

Innerhalb meines Systems sind Avatare entweder aus dem S3 oder dem CDN verfügbar. Dies deutet darauf hin, dass die Avatar-URL irgendwo/irgendwie in eine CDN-URL umgewandelt wird.

Wenn dies geschieht, betrachtet das CDN die URL als direkten Zugriffslink und blockiert den Zugriff mit einem 403.

Hoffentlich habe ich die “dies”-Frage beantwortet?

Und ich hasse es, wenn Leute so antworten, wenn ich meine Zeit damit verbringe, ihnen zu helfen, also ist es ein Unentschieden :wink:.

Ja, und „Proxy“ bedeutet, dass die Anfrage durch Discourse läuft. Die Anfrage wird nicht vom Browser an das CDN gestellt, sondern von Discourse.

Haben Sie das CDN als Full-Site-CDN oder als S3-CDN eingerichtet? Ich vermute Letzteres. Und in diesem Fall wird die Anfrage von Discourse an das CDN gestellt, ohne Referrer. Das CDN kann jedoch immer noch erkennen, dass es sich um eine legitime Anfrage handelt, da die Anfrage von der Discourse-IP stammt. Daher mein Rat, sie auf die Whitelist zu setzen.

Bearbeiten: Sie könnten dies überprüfen, indem Sie den Schutz für eine kurze Weile ausschalten und die Protokolle in Bunny einsehen, um zu sehen, von welcher IP sie stammen.

Ich schätze Ihre Hilfe. Nach jahrzehntelanger Arbeit in der IT-Entwicklung und im Support verursachen vage Fragen und Antworten mehr Arbeit als nötig. Basierend auf Ihrer Erfahrung, denke ich, würden Sie zustimmen.

Das CDN ist nur für den S3-Bucket eingerichtet.

Ich habe die CDN-Protokolle für die Discourse-IP im Zusammenhang mit den 403-Fehlern überprüft, bevor ich das ursprüngliche Thema eingereicht habe. Sie waren nicht in den Protokolldateien enthalten.

Basierend auf Ihren Kommentaren habe ich die Protokolle erneut analysiert. Nach der Überprüfung der größten IP-Übeltäter habe ich festgestellt, dass die beiden Spitzenreiter Gateways für das Hosting-Unternehmen sind.

Die Herausforderung besteht darin, dass ich die Gateway-IP-Adressen von Digital Ocean nicht im Auge behalten möchte, damit mein Discourse-Server Bilder korrekt anzeigen kann.

Vielen Dank für Ihre Hilfe.