500er-Fehler bei der Anforderung benutzerdefinierter Avatare von Benutzern

Ich habe versucht, einen benutzerdefinierten Avatar hochzuladen. Er konnte erfolgreich hochgeladen werden, aber bei der Anfrage an https://example.com/user_avatar/example.com/example_user/96/11_2.png wurde nur ein 500er-Fehler zurückgegeben. Der Standard-Avatar für anonyme Benutzer hat diesen Fehler nicht.

Neuester master-Branch von Discourse.
Cloudflare R2 wird als mein S3-Speicher verwendet.

Befinden Sie sich auf einer unsupported-install?

In jedem Fall reichen 500 allein nicht aus. Bitte teilen Sie die zugehörigen Protokollinformationen mit, und vielleicht hilft Ihnen jemand.

2 „Gefällt mir“

Natürlich. Übrigens habe ich Cloudflare R2 (S3-kompatibel) zum Speichern von Upload-Inhalten verwendet. Als ich die Dateien im Bucket überprüft habe, war die Avatar-Datei tatsächlich vorhanden, aber die Clients konnten nicht darauf zugreifen mit https://example.com/user_avatar/example.com/example_user/96/11_2.png, das ist so seltsam.

In production.log habe ich diese Zeile gefunden:

Processing by UserAvatarsController#show as PNG
  Parameters: {"hostname" => "echonet.icu", "username" => "where", "size" => "288", "version" => "12_2"}
Completed 418 in 599ms (Views: 4.1ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.4ms)

Dies könnte zusammenhängen mit:

Könnte ein S3-Problem mit der neuesten Version sein :thinking:.

Okay, ich hoffe, es ist nur ein Problem der aktuellen Nightly-Version. Es wurde durch die Einstellung eines Proxys gelöst.

Hallo @MoRanYue, könntest du genauer erklären, wie du es gelöst hast?

Ich stehe vor dem gleichen Problem.

Danke

@avidseeker
Wenn Sie einen OSS-Dienst nutzen und Ihr Server darauf nicht zugreifen kann, zum Beispiel, wenn Sie sich in China befinden und die Verbindungen Ihres Servers zu Cloudflare R2 vom lokalen ISP blockiert werden. Wenn Clients versuchen, benutzerdefinierte Avatar-Ressourcen abzurufen, muss Ihr Server diese vom OSS abrufen, aber wenn dies fehlschlägt, wird den Clients ein 500er-Fehler zurückgegeben.

In meinem Fall habe ich zwei Umgebungsvariablen gesetzt: HTTP_PROXY und HTTPS_PROXY auf einen Proxyserver, der auf Ihren OSS-Dienst zugreifen kann. Wenn Sie Discourse mit der Standardinstallation installiert haben, sollte in Ihrer app.xml ein Feld namens env vorhanden sein. Fügen Sie diese beiden Variablen hinzu und führen Sie dann aus. Ich habe eine nicht unterstützte Installation verwendet und Systemd zur Verwaltung von Discourse verwendet, daher habe ich zwei Environment-Parameter in die .service-Datei eingefügt.

Ich weiß nicht, ob Ihr Land ein Netzwerkzensursystem hat. Wenn ja, kann ich davon ausgehen, dass Sie bereits wissen, was zu tun ist; Wenn nicht, überprüfen Sie den Online-Status Ihres OSS-Dienstes und Ihre Einstellungen zu S3.

1 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.