Erreur Discourse_docker (blocked:csp) avec svg-sprite lors de l'utilisation de sous-dossiers

N’hésitez pas à visiter https://sales-community-staging.rainmakers.co/sales-community/ pour voir le problème. Aucune garantie qu’il restera accessible indéfiniment.
Je pense que c’est parce que /sales-community n’est pas ajouté à l’URL.
Faites-moi savoir si fournir app.yml ou nginx.conf serait utile.
Cela concerne la version: tests-passed.
J’ai essayé version: stable pour corriger le problème, mais cela ne se compile pas dans Docker pour le moment (mentionné dans un autre rapport de bug que j’ai vu plus tôt ; je repartais de zéro, pas d’une mise à niveau).

Quelqu’un peut-il me permettre de publier plus d’une image ? :slight_smile:

1 « J'aime »

Avez-vous suivi le document didacticiel sur les sous-dossiers ?

Oui. Tout le reste fonctionne (publication, e-mails, téléchargement d’avatars, HTTPS, etc.). Toutes les autres ressources ont des URLs de sous-dossier /sales-community correctes (comme illustré sur la capture d’écran). Seul le SVG est cassé.

# 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

Oui, le problème ne vient pas de la CSP car l’URL est tout simplement incorrecte : elle n’est apparemment pas préfixée par le chemin du sous-dossier. Je pense qu’il faut l’ajouter ici ?

4 « J'aime »

Hmm, est-ce un bug de sous-dossier @eviltrout ?

Nous avons bien toute la logique en place pour les sprites SVG dans les scénarios de sous-dossiers, et elle est utilisée avec succès par plusieurs sites. Dans ce cas précis, nous avons rencontré un cas limite très spécifique. En examinant les variables clés sur le site de @vkozyrev (via la console du navigateur) :

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

Tout semble correct. Maintenant, lorsque nous chargeons la feuille de sprites SVG, nous utilisons loadScript, qui appelle à son tour Discourse.getURL. Cette fonction est chargée d’ajouter le préfixe du sous-dossier. Essayons :

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

Hé… cela n’a rien fait. Un autre URL aléatoire fonctionne correctement :

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

En creusant un peu plus, on tombe sur cette ligne à l’intérieur de getUrl :

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

Ou, en français : « si l’URL contient déjà le préfixe du sous-dossier, on abandonne ». Le problème ici est que le préfixe du sous-dossier de @vkozyrev (/sales-community) est inclus au milieu de l’URL de la feuille de sprites SVG :

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

J’ai rendu la vérification plus précise, de sorte qu’elle ne vérifie le préfixe du sous-dossier qu’au début de l’URL :

Cela me fait cependant penser à d’autres problèmes potentiels… par exemple, si quelqu’un voulait que son préfixe de sous-dossier soit /t ou /about, ou toute autre URL que nous utilisons dans Discourse :thinking:

10 « J'aime »

@vkozyrev c’est maintenant fusionné, veuillez donc mettre à jour votre site et nous faire savoir si cela résout le problème :slight_smile:

Le problème est résolu @david.

C’est un cas limite incroyable :smiley:. Je développe en Rails (mode API uniquement), heureux de ne pas être allé trop loin dans le terrier du lapin, je me serais perdu dans le code client.

Au cas où vous seriez curieux, j’ai un proxy devant cela, donc le sous-domaine sales-community est caché aux utilisateurs ; ils ne verront que /sales-community devant l’URL de notre site principal. Le site principal est hébergé sur Heroku, je ne peux donc pas avoir une seule instance nginx qui gère tout.

Merci pour vos réponses rapides et la correction à tous !

6 « J'aime »