Errore Discourse_docker (blocked:csp) con svg-sprite quando si usano sottocartelle

Contribuisci Bug
1

Sentiti libero di visitare https://sales-community-staging.rainmakers.co/sales-community/ per vedere il problema. Non ci sono garanzie che rimanga attivo per sempre.
Penso che sia dovuto al fatto che non sta aggiungendo /sales-community all’URL.
Fammi sapere se fornire app.yml o nginx.conf sarebbe utile.
Questo è su version: tests-passed.
Ho provato version: stable per risolvere, ma al momento non compila su docker (menzionato in un altro rapporto di bug che ho visto prima; stavo ricominciando da capo, non stavo facendo un downgrade)

Screen Shot 2020-01-22 at 6.48.00 PM
Screen Shot 2020-01-22 at 6.48.00 PM1277×1364 349 KB

Qualcuno può darmi la possibilità di pubblicare più di un’immagine :slight_smile:

1 Mi Piace
2

Hai seguito la guida nella sottocartella?

3

Sì. Tutto il resto funziona (pubblicazione, email, caricamento avatar, HTTPS, ecc.). Tutte le altre risorse hanno URL corretti nella sottocartella /sales-community (come mostrato nell’immagine). Solo l’SVG è rotto.

# app.yml

altre cose...

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

altre cose...

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
4

Sì, quindi il problema non è legato alla CSP perché l’URL è semplicemente errato; a quanto pare non viene preceduto dal percorso della sottocartella. Credo che debba essere aggiunto qui.

4 Mi Piace
5

Hmm, è un bug della sottocartella @eviltrout?

9

Abbiamo già tutta la logica necessaria per gli sprite SVG nei casi di sottocartelle, ed è utilizzata con successo da diversi siti. In questo caso, però, ci siamo imbattuti in un caso limite molto specifico. Controllando le variabili chiave nel sito di @vkozyrev (nella console del browser):

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

Tutto sembra corretto. Ora, quando carichiamo il foglio degli sprite SVG, utilizziamo loadScript, che a sua volta chiama Discourse.getURL. Questa funzione è responsabile dell’aggiunta del prefisso della sottocartella. Proviamo:

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

Strano… non ha fatto nulla. Un altro URL casuale funziona invece correttamente:

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

Un’ulteriore indagine rivela questa riga all’interno di getUrl

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

Ovvero, in italiano: “se l’URL contiene già il prefisso della sottocartella, desisti”. Quindi il problema qui è che il prefisso della sottocartella di @vkozyrev (/sales-community) è incluso a metà dell’URL del foglio degli sprite SVG

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

Ho reso il controllo più specifico, in modo che verifichi il prefisso della sottocartella solo all’inizio dell’URL:

Ciò mi fa però pensare ad altre potenziali problematiche… ad esempio, se qualcuno volesse impostare il proprio prefisso di sottocartella come /t o /about, o qualsiasi altro URL utilizzato in Discourse :thinking:

10 Mi Piace
Recent Changes Breaking Subfolder Setup?
10

@vkozyrev è stato unito, quindi aggiorna il tuo sito e facci sapere se risolve il problema :slight_smile:

11

Il problema è stato risolto @david.

Questo è un caso limite incredibile :smiley:. Sviluppo in Rails (solo modalità API), sono contento di non essere andato troppo in profondità nella tana del coniglio, altrimenti mi sarei perso nel codice client.

Nel caso foste curiosi, ho un proxy davanti a questo, quindi il sottodominio sales-community è nascosto agli utenti: vedranno solo /sales-community all’inizio dell’URL del nostro sito principale. Il sito principale è su Heroku, quindi non posso usare un’unica istanza di nginx per instradare tutto.

Grazie per le risposte rapide e per la correzione a tutti!

6 Mi Piace