Verursacht DISCOURSE_CDN_URL Content-Security-Policy-Verstöße?

Unterstützung Installation
1

Ich weiß nicht, wie ich das so falsch mache. Ich kann nicht verstehen, warum ich der Einzige bin, der mit einem vermeintlichen Fehler konfrontiert ist.

Wenn ich

  DISCOURSE_CDN_URL: https://lcsupport-92e2.kxcdn.com

im env:-Abschnitt meiner yml-Datei für eine relativ Standard-Multisite-Konfiguration definiere, werden alle CDN-URLs vom Browser aufgrund eines CSP-Fehlers abgelehnt.

content security policy script src behauptet: „Zusätzlich freigegebene Skriptquellen. Der aktuelle Host und das CDN sind standardmäßig enthalten. Siehe XSS-Angriffe mit Content Security Policy abmildern.". Doch wenn ich es definiere (oder es in discourse.conf hinzufüge/entferne und sv restart unicorn ausführe), erhalte ich folgende Meldung:

image
image811×296 62.4 KB

Selbst wenn content security policy report only auf true gesetzt ist, wird die Seite nicht geladen.

Es scheint erforderlich zu sein, content_security_policy zu deaktivieren oder die CDN-URL zu content security policy script src hinzuzufügen, damit der Browser die Assets laden kann.

Hier ist meine yml-Datei.

2

CDN-URLs sollten standardmäßig berechnet und in die CSP aufgenommen werden. Könntest du bitte auch die tatsächlich im Header bereitgestellte CSP und die Quelle der blockierten Assets angeben (oder einen Vergleich versuchen)?

3

Hier ist der Header:

content-security-policy-report-only: base-uri 'none'; object-src 'none'; script-src 'report-sample' 
https://support.literatecomputing.com/logs/ 
https://support.literatecomputing.com/sidekiq/ 
https://support.literatecomputing.com/mini-profiler-resources/ 
https://abedmulti-92e2.kxcdn.com/uploads/assets/ 
https://abedmulti-92e2.kxcdn.com/uploads/brotli_asset/ 
https://support.literatecomputing.com/extra-locales/ 
https://lcsupport-92e2.kxcdn.com/highlight-js/ 
https://lcsupport-92e2.kxcdn.com/javascripts/ 
https://lcsupport-92e2.kxcdn.com/plugins/ 
https://lcsupport-92e2.kxcdn.com/theme-javascripts/ 
https://lcsupport-92e2.kxcdn.com/svg-sprite/ 
https://www.google-analytics.com/analytics.js 
https://tagmanager.google.com/ 
https://www.googletagmanager.com/; worker-src 'self' blob:

Hier sind die ENV-Variablen innerhalb des Containers:

root@support-multi:/var/www/discourse# echo $DISCOURSE_S3_UPLOAD_BUCKET 
abed-multi/uploads
root@support-multi:/var/www/discourse# echo $DISCOURSE_S3_CDN_URL 
https://abedmulti-92e2.kxcdn.com/uploads

Hier ist die CDN-URL aus discourse.conf:

cdn_url = 'https://lcsupport-92e2.kxcdn.com'

und rails:

[1] pry(main)> GlobalSetting.cdn_url
=> "https://lcsupport-92e2.kxcdn.com"

Und hier ist die URL für eine der Assets, die nicht geladen werden: https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js

4

Wir haben also dies in der CSP:

https://abedmulti-92e2.kxcdn.com/uploads/assets/
https://abedmulti-92e2.kxcdn.com/uploads/brotli_asset/
# d. h. DISCOURSE_S3_CDN_URL + /brotli_asset/

Die tatsächliche Adresse lautet jedoch:

https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js
# d. h. DISCOURSE_CDN_URL + /brotli_asset/...

Der relevante CSP-Code:

Wir priorisieren die Verwendung von DISCOURSE_S3_CDN_URL für Assets, wenn verfügbar. Dies entspricht der Generierung von CDN-Asset-URLs.

@pfaffman: Gibt GlobalSetting.use_s3? für deine Seite true zurück?

Ich frage mich, ob wir hier eine zusätzliche Prüfung auf GlobalSetting.use_s3? benötigen. Bedeutet das Vorhandensein von GlobalSetting.s3_cdn_url zwangsläufig, dass GlobalSetting.use_s3? zutrifft? Bei der Asset-Generierung und dem S3-CDN bin ich gerade etwas unsicher :sweat_smile: – könnte sich jemand, der damit besser vertraut ist, das auch ansehen? Danke!

5

Nun, ich habe use_s3 gesetzt und dann rake assets:precompile ausgeführt, aber es hat sich nichts geändert.

Ich hatte dieses Problem schon einmal anderswo, bei dem Unklarheit bestand, ob die Assets in S3 oder lokal (oder deren CDN-Mirrors) lagen.