Neue Änderungen brechen das Subordner-Setup?

[hartz (adam hartz)]

Entschuldigung, falls ich das falsch eingeschätzt habe, aber ich habe kürzlich nach einem Upgrade in einer Subfolder-Konfiguration, die zuvor problemlos funktioniert hat, einige Probleme festgestellt. Daher vermute ich, dass es in jüngster Zeit auf einigen Ebenen zu Regressionen gekommen sein könnte? Insbesondere hoste ich Discourse selbst in der hier beschriebenen Subfolder-Konfiguration hier, die bis vor kurzem (soweit ich weiß) einwandfrei lief.

Derzeit werde ich beim Einloggen über SSO oder beim Wechseln in den/aus dem anonymen Modus (und vielleicht auch in anderen, mir noch unbekannten Situationen) zu https://my_machine/discourse_path_stuff weitergeleitet, anstatt zu https://my_machine/forum/discourse_path_stuff. Außerdem wird meine Adressleiste, wenn ich zu https://my_machine/forum (dem richtigen Endpunkt) navigiere, so umgeschrieben, dass dort https://my_machine steht (der Subfolder wird entfernt), obwohl die meisten Links anscheinend an die richtigen Stellen führen.

Leider kann ich mich nicht mehr daran erinnern, an welchem Commit ich gearbeitet habe, als alles noch funktionierte, aber ich bin mir ziemlich sicher, dass es sich um einen unter dem “2.4.0.beta10”-Label fallenden Commit handelte, wahrscheinlich innerhalb der letzten ~10 Tage. Aktuell laufe ich auf bd49d4af1a.

Ich entschuldige mich, falls ich nur etwas Dummes mache, und bin gerne bereit, bei der Fehlersuche zu helfen, falls Sie Vorschläge haben, wo ich suchen sollte.

[Falco]

Können Sie die Site-URL teilen? Nutzen Sie unser SSO-Protokoll oder eine OAuth2-/Omniauth-Strategie?

[hartz (adam hartz)]

Klar, er befindet sich unter https://py.mit.edu/forum (ist aber derzeit für die Öffentlichkeit gesperrt). https://py.mit.edu/forum/login zeigt das Problem (obwohl ich nach Auftreten dieses Problems eine zusätzliche NGINX-Regel eingefügt habe, die https://py.mit.edu/login mit einem 302-Statuscode zurück zu https://py.mit.edu/forum/login umleitet; das ist zumindest eine Workaround-Lösung für den SSO-Teil).

Wir verwenden das Discourse-SSO-Protokoll, das bisher problemlos funktioniert hat. Der Handshake scheint weiterhin korrekt abzulaufen, es wird nur am Ende an die falsche Stelle umgeleitet. Der Schlüssel "return_sso_url" im SSO-Payload wird jedoch korrekt an unseren SSO-Endpunkt zurückgesendet (mit /forum).

Ich habe auch einen Rebuild versucht, aber das hat das Problem nicht behoben.

Leider könnte die Fehlersuche schwierig sein, da ich Außenstehenden keinen Zugriff gewähren möchte, da diese Instanz für einen Kurs genutzt wird und ich keine Bedenken habe, Studentendaten mit externen Parteien zu teilen (auch wenn ich dir persönlich vertraue!). Wenn es jedoch hilft, bin ich gerne bereit, dieses Setup auf einem anderen Server zu replizieren, auf den ich dir Zugang gewähren könnte…

[hartz (adam hartz)]

Ich sehe auch, dass der Link zum Betreten/Verlassen des anonymen Modus window.location.reload() verwendet, um die Seite neu zu laden, nachdem eine Anfrage an einen Endpunkt gesendet wurde, um in den anonymen Modus zu wechseln. Dieser Neuladevorgang würde definitiv die umgeschriebene URL sehen (die nicht mehr /forum enthält), was dies verursachen würde (ich bin mir nicht sicher, ob es bei den SSO-Problemen ähnlich ist).

Ich werde mir die letzten Changesets ansehen, um zu prüfen, ob das, was (wie ich denke?) window.location umschreibt, eine kürzliche Ergänzung ist.

Außerdem liefert Discourse.getURL('/login') immer noch das richtige Ergebnis (mit /forum).

[bokos]

Die Pfade werden ohne Subordner-Präfix in der Adressleiste des Browsers zurückgesetzt.

Beispiel:
Ich besuche example.com/forum → nach dem Laden des Forums zeigt die Adressleiste example.com.
Dann klicke ich auf „Neueste“ → es wird zu „Neueste“ navigiert und die Adressleiste zeigt example.com/forum/latest.
Ich aktualisiere die Seite im Browser, die Website wird neu geladen und die Adressleiste zeigt example.com/latest.
Wenn ich erneut aktualisiere, während ich mich auf example.com/latest befinde, tritt ein 404-Fehler auf (da mein Nginx nur /forum an Discourse weiterleitet).

Die Link-Vorschau unten links im Browser wird als example.com/latest, example.com/new usw. angezeigt. Das Aktualisieren eines Themas entfernt ebenfalls /forum aus der URL, aber anschließend ändert es sich wieder zurück zu /forum/t/[…].

Ich war zuvor in der Version 2.4.0.beta2 und erinnere mich nicht an dieses Problem.

[Falco]

Wurde diese Installation gemäß Unterordner-Unterstützung mit Docker erstellt? Können Sie einen Link dazu bereitstellen?

[bokos]

Ja, ich habe es auch auf einer frischen lokalen Installation ausprobiert und das gleiche Problem erhalten:

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;
          }

[jomaxro (Joshua Rosenfeld)]

Ich kann das Problem auf meiner Installation im Unterordner reproduzieren. Wir werden das beheben.

[hartz (adam hartz)]

Super, danke! Schön zu wissen, dass ich nicht verrückt bin.

Beim Stöbern in den jüngsten Commits konnte ich jedoch keinen offensichtlichen Punkt finden, an dem diese Umstrukturierung stattfindet. Wäre es möglich, einen Hinweis darauf zu bekommen, wo im Code dies geschieht/geschah? (Ich bin gerade dabei, mich mit der Codebasis vertraut zu machen).

[jomaxro (Joshua Rosenfeld)]

@hartz

Wäre es möglich, einen Hinweis darauf zu bekommen, wo im Code dies passiert ist oder passiert?

Das wäre möglich! Ich bin nur nicht der richtige Ansprechpartner. Ich bin nur „dieser Typ

[david (David Taylor)]

@hartz

Wo im Code?

Fast sicher diese Änderung, die für dieses Problem gemacht wurde. Ich bin mir nicht ganz sicher, was das Problem genau ist, aber ich werde mich darum kümmern

[david (David Taylor)]

Es stellte sich heraus, dass es völlig unabhängig von diesem Commit war. Ich habe die Ursache des Problems gefunden, und eine Lösung ist in Arbeit:

FIX: Subfolder sites rewriting URLs to root domain on initial load (#8932)

[zogstrip]

Ausgezeichnete Detektivarbeit , @david

[david (David Taylor)]

Das ist jetzt gemerged – @hartz und @bokos, könnt ihr bitte bestätigen, dass das Problem nach einem Update behoben ist?

[hartz (adam hartz)]

Nach ein wenigem Testen scheinen die Dinge tatsächlich wieder zu funktionieren. Danke, @david!