Discourse_docker (blocked:csp) Fehler mit svg-sprite bei Verwendung von Unterordnern

Fühlen Sie sich frei, https://sales-community-staging.rainmakers.co/sales-community/ zu besuchen, um das Problem zu sehen. Keine Garantie dafür, dass es für immer verfügbar bleibt.
Ich glaube, das liegt daran, dass /sales-community nicht zur URL hinzugefügt wird.
Lassen Sie mich wissen, ob es hilfreich wäre, app.yml oder nginx.conf bereitzustellen.
Dies ist auf version: tests-passed.
Ich habe version: stable versucht, um es zu beheben, aber es kompiliert derzeit nicht unter Docker (in einem anderen Fehlerbericht, den ich früher gesehen habe, erwähnt; ich habe von vorne begonnen, nicht herabgestuft).

Kann mir jemand die Möglichkeit geben, mehr als ein Bild zu posten? :slight_smile:

1 „Gefällt mir“

Haben Sie das Dokument zur Handhabung von Unterordnern befolgt?

Ja. Alles andere funktioniert (Beiträge erstellen, E-Mails, Avatar-Uploads, HTTPS usw.). Alle anderen Ressourcen haben korrekte URLs mit dem Unterordner /sales-community (wie im Bild gezeigt). Nur das SVG ist defekt.

# app.yml

stuff...

DISCOURSE_HOSTNAME: sales-community.rainmakers.co
DISCOURSE_RELATIVE_URL_ROOT: /sales-community

stuff...

run:
    - exec:
        cd: $home
        cmd:
          - mkdir -p public/sales-community
          - cd public/sales-community && ln -s ../uploads && ln -s ../backups
    - replace:
       global: true
       filename: /etc/nginx/conf.d/discourse.conf
       from: proxy_pass http://discourse;
       to: |
          rewrite ^/(.*)$ /sales-community/$1 break;
          proxy_pass http://discourse;
    - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: etag off;
       to: |
          etag off;
          location /sales-community {
             rewrite ^/sales-community/?(.*)$ /$1;
          }
    - replace:
         filename: /etc/nginx/conf.d/discourse.conf
         from: $proxy_add_x_forwarded_for
         to: $http_your_original_ip_header
         global: true

Ja, das Problem liegt also nicht bei CSP, da die URL einfach falsch ist. Sie wird anscheinend nicht mit dem Unterordner-Pfad vorangestellt. Ich denke, das muss hier hinzugefügt werden: hier.

4 „Gefällt mir“

Hmm, ist das ein Unterordner-Fehler @eviltrout?

Wir haben die gesamte Logik für SVG-Sprites in Unterordner-Szenarien bereits implementiert, und sie wird von mehreren Sites erfolgreich genutzt. In diesem Fall sind wir jedoch auf einen sehr spezifischen Randfall gestoßen. Ein Blick auf die relevanten Variablen auf @vkozyrevs Site (in der Browserkonsole):

> Discourse.SvgSpritePath
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
> Discourse.BaseUri
"/sales-community"

Sieht gut aus. Wenn wir nun das SVG-Sprite-Sheet laden, verwenden wir loadScript, das wiederum Discourse.getURL aufruft. Diese Funktion ist dafür zuständig, das Unterordner-Präfix hinzuzufügen. Testen wir das:

> Discourse.getURL(Discourse.SvgSpritePath)
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"

Hm… das hat nichts bewirkt. Eine andere zufällige URL funktioniert hingegen einwandfrei:

> Discourse.getURL("/blah")
"/sales-community/blah"

Beim weiteren Nachforschen stießen wir auf diese Zeile innerhalb von getUrl:

if (url.indexOf(Discourse.BaseUri) !== -1) return url;

Oder auf Deutsch: „Wenn die URL bereits das Unterordner-Präfix enthält, abbrechen.“ Das Problem ist also, dass @vkozyrevs Unterordner-Präfix (/sales-community) in der Mitte der SVG-Sprite-Sheet-URL enthalten ist:

/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js

Ich habe die Prüfung nun präziser gestaltet, sodass sie nur das Unterordner-Präfix am Anfang der URL überprüft:

Das lässt mich allerdings an andere potenzielle Probleme denken… z. B. wenn jemand sein Unterordner-Präfix als /t oder /about oder eine andere URL wählen möchte, die wir in Discourse verwenden :thinking:

10 „Gefällt mir“

@vkozyrev das ist jetzt gemerged, also bitte aktualisiere deine Seite und lass uns wissen, ob das Problem damit behoben ist :slight_smile:

Das Problem ist behoben, @david.

Das ist ein erstaunlicher Randfall :smiley:. Ich entwickle in Rails (nur im API-Modus). Ich bin froh, nicht allzu tief ins Kaninchenloch gestiegen zu sein – sonst wäre ich im Client-Code völlig verloren gewesen.

Falls Sie neugierig sind: Ich habe einen Proxy davor geschaltet, sodass die Subdomain sales-community für die Nutzer verborgen bleibt. Sie sehen nur /sales-community vor der URL unserer Hauptseite. Die Hauptseite läuft auf Heroku, daher kann ich nicht eine einzelne nginx-Instanz für das gesamte Routing verwenden.

Vielen Dank für die schnellen Antworten und die Lösung, zusammen mit allen anderen!

6 „Gefällt mir“