Les récentes modifications perturbent-elles la configuration des sous-dossiers ?

Contribuer Bug
1

Désolé si j’ai mal diagnostiqué le problème, mais j’ai récemment rencontré quelques soucis après une mise à niveau sur une configuration en sous-dossier qui fonctionnait auparavant. Je pense donc qu’il pourrait y avoir eu une régression sur certains points récemment ? En particulier, j’héberge moi-même Discourse en utilisant la configuration en sous-dossier décrite ici, qui fonctionnait sans problème (à ma connaissance) jusqu’à récemment.

Actuellement, lors de la connexion via SSO ou lors du passage au mode anonyme (et peut-être dans d’autres situations que je n’ai pas encore identifiées), je suis redirigé vers https://my_machine/discourse_path_stuff, au lieu d’être redirigé vers https://my_machine/forum/discourse_path_stuff. De plus, lorsque je vais sur https://my_machine/forum (le bon point de terminaison), ma barre d’adresse est réécrite pour afficher https://my_machine (le sous-dossier étant supprimé), bien que la plupart des liens semblent être résolus correctement.

Malheureusement, je ne me souviens pas du commit exact sur lequel j’étais lorsque tout fonctionnait, mais je suis presque certain qu’il s’agissait de la version “2.4.0.beta10”, probablement il y a environ 10 jours. Je tourne actuellement sur bd49d4af1a.

Je m’excuse si je fais simplement quelque chose de stupide, et je suis heureux de vous aider à identifier le problème si vous avez des suggestions sur où je devrais chercher.

1 « J'aime »
Subfolder trailing slash issue
Blank main page on one forum (subfolder + multisite install)
2

Pouvez-vous partager l’URL du site ? Utilisez-vous notre protocole SSO ou une stratégie OAuth2 / omniauth ?

2 « J'aime »
3

Bien sûr, il se trouve à https://py.mit.edu/forum (mais il est actuellement inaccessible au public). https://py.mit.edu/forum/login illustre le problème (bien que j’aie ajouté une règle NGINX spécifique pour rediriger en 302 https://py.mit.edu/login vers https://py.mit.edu/forum/login depuis que nous avons constaté ce problème, ce qui constitue une solution de contournement pour la partie SSO, du moins).

Nous utilisons le protocole SSO de Discourse, qui fonctionnait parfaitement auparavant. La poignée de main semble toujours se dérouler correctement, mais la redirection finale se fait vers le mauvais endroit. La clé "return_sso_url" dans la charge utile SSO revient correctement à notre point de terminaison SSO (avec /forum).

J’ai également tenté une reconstruction, mais cela n’a pas semblé résoudre le problème.

Malheureusement, cela pourrait être difficile à déboguer car je ne me sens pas à l’aise à l’idée de donner accès à des personnes extérieures, car cette instance est destinée à un cours et je ne souhaite pas partager les données des étudiants avec des tiers (même si je vous fais confiance personnellement !). Cependant, si cela peut aider, je suis heureux de tenter de reproduire cette configuration sur un autre serveur auquel je pourrais vous donner accès…

3 « J'aime »
4

Je remarque également que le lien pour entrer/sortir du mode anonyme utilise window.location.reload() pour recharger la page après avoir envoyé une requête à un point de terminaison afin de basculer en mode anonyme. Ce rechargement verrait donc assurément l’URL réécrite (ne contenant plus /forum), ce qui provoquerait ce problème (je ne sais pas si c’est une histoire similaire pour les problèmes SSO).

Je vais jeter un coup d’œil aux derniers changements pour voir si l’élément qui (je pense ?) réécrit window.location est une ajout récent.

De plus, Discourse.getURL('/login') me donne toujours le bon résultat (avec /forum).

1 « J'aime »
8

Les chemins sont réinitialisés sans le préfixe du sous-dossier dans la barre d’adresse du navigateur.

Exemple :
Je visite example.com/forum → une fois le forum chargé, la barre d’adresse affiche example.com
Ensuite, je clique sur « Derniers » → la navigation vers « derniers » s’effectue et la barre d’adresse affiche example.com/forum/latest
J’actualise la page dans le navigateur, le site se recharge et la barre d’adresse affiche example.com/latest
Lorsque j’actualise à nouveau alors que je suis sur example.com/latest, une erreur 404 apparaît (car mon nginx ne route que /forum vers Discourse).

L’aperçu du lien en bas à gauche du navigateur s’affiche comme example.com/latest, example.com/new, etc. L’actualisation d’un sujet supprime également /forum de l’URL, mais cela change ensuite à nouveau, pour revenir à /forum/t/[…].

J’étais précédemment sur la version 2.4.0.beta2 et je ne me souviens pas de ce problème.

3 « J'aime »
9

Cette installation a-t-elle été créée en suivant la prise en charge des sous-dossiers avec Docker ? Pouvez-vous fournir un lien vers celle-ci ?

7 « J'aime »
10

Oui, j’ai également essayé sur une installation locale fraîche et j’ai obtenu le même problème :

app.yml

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"

expose:
 - 80:80

params:
  db_default_text_search_config: "pg_catalog.english"
  version: tests-passed

env:
  LANG: en_US.UTF-8
  UNICORN_WORKERS: 3
  DISCOURSE_RELATIVE_URL_ROOT: /forum
  DISCOURSE_HOSTNAME: localhost
  DISCOURSE_DEVELOPER_EMAILS: yyy

  DISCOURSE_SMTP_ADDRESS: yyy
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: yyy@yyy.yyy
  DISCOURSE_SMTP_PASSWORD: yyy
  DISCOURSE_SMTP_AUTHENTICATION: login

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
            - git clone https://github.com/discourse/docker_manager.git

run:
    - exec:
        cd: $home
        cmd:
          - mkdir -p public/forum
          - cd public/forum && ln -s ../uploads && ln -s ../backups
    - replace:
       global: true
       filename: /etc/nginx/conf.d/discourse.conf
       from: proxy_pass http://discourse;
       to: |
          rewrite ^/(.*)$ /forum/$1 break;
          proxy_pass http://discourse;
    - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: etag off;
       to: |
          etag off;
          location /forum {
             rewrite ^/forum/?(.*)$ /$1;
          }
5 « J'aime »
11

Je peux reproduire le problème sur mon installation dans un sous-dossier. Nous allons régler cela.

6 « J'aime »
12

Super, merci ! Content de savoir que je ne suis pas fou.

En fouillant dans les commits récents, je n’ai pas pu repérer de point évident où cette réécriture se produit. Serait-il possible d’avoir un indice sur l’endroit dans le code où cela se passe ou se passait ? (Je suis en train d’essayer de me familiariser avec la base de code).

1 « J'aime »
13

Ce serait possible ! Je ne suis simplement pas la bonne personne. Je suis juste « ce gars » de l’équipe qui se trouve avoir une installation dans un sous-dossier local. Mais je ne suis pas ingénieur. David devrait pouvoir vous orienter dans la bonne direction lorsqu’il commencera à travailler sur le problème plus tard cette semaine.

6 « J'aime »
14

Presque certainement ce changement qui concernait ce problème. Je ne suis pas exactement sûr de ce qu’est le problème, mais je vais m’en occuper :eyes:

6 « J'aime »
15

Il s’avère que cela était complètement sans rapport avec ce commit. J’ai identifié la source du problème, et une correction est en cours de préparation :

12 « J'aime »
16

Excellent travail d’enquêteur :man_detective: @david :clap:

6 « J'aime »
17

Ceci est maintenant fusionné - @hartz et @bokos, pouvez-vous confirmer que le problème est résolu après une mise à jour ?

5 « J'aime »
18

Après un peu de tests, les choses semblent effectivement fonctionner à nouveau. Merci, @david !

2 « J'aime »