Retour de 500 lors de la demande d'avatars personnalisés des utilisateurs

J’ai essayé de télécharger un avatar personnalisé, il a pu être téléchargé avec succès, mais lors de la demande de https://example.com/user_avatar/example.com/example_user/96/11_2.png, cela a juste renvoyé une erreur 500. L’avatar anonyme par défaut n’a pas cette erreur.

Dernière branche master de Discourse.
Cloudflare R2 est utilisé comme mon stockage S3.

Êtes-vous sur une #installation-non-prise-en-charge ?

Dans tous les cas, 500 n’est pas une information suffisante. Veuillez partager les informations de journalisation pertinentes et quelqu’un pourrait vous aider.

2 « J'aime »

Bien sûr. D’ailleurs, j’ai utilisé Cloudflare R2 (compatible S3) pour stocker le contenu téléchargé. Lorsque j’ai vérifié les fichiers dans le bucket, le fichier avatar était bien là, mais les clients ne pouvaient pas y accéder avec https://example.com/user_avatar/example.com/example_user/96/11_2.png, c’est tellement bizarre.

Dans production.log, j’ai trouvé cette ligne :

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)

Ceci peut être lié à :

Il pourrait s’agir d’un problème S3 avec la dernière version :thinking:.

Ok, j’espère que ce n’est qu’un problème lié à la version nocturne actuelle. C’est résolu en configurant un proxy.

Salut @MoRanYue, pourriez-vous en dire plus sur la façon dont vous l’avez résolu ?

Je rencontre le même problème.

Merci

@avidseeker
Lorsque vous utilisez un service OSS et que votre serveur ne peut pas y accéder, par exemple, vous êtes en Chine et les connexions de votre serveur à Cloudflare R2 sont bloquées par le FAI local. Lorsque les clients essaient d’acquérir des ressources d’avatar personnalisées, votre serveur doit les acquérir auprès de l’OSS, mais échoue, puis renvoie 500 aux clients.

Dans mon cas, j’ai défini deux variables d’environnement : HTTP_PROXY et HTTPS_PROXY vers un serveur proxy capable d’accéder à votre service OSS. Si vous avez installé Discourse avec l’installation standard, dans votre app.xml il devrait y avoir un champ appelé env, ajoutez ces deux variables, puis vous pourrez exécuter. J’ai utilisé une installation non prise en charge et j’utilise Systemd pour gérer Discourse, j’ai donc ajouté deux paramètres Environment dans le fichier .service.

Je ne sais pas si votre pays a un système de censure réseau. Si c’est le cas, je peux supposer que vous savez déjà quoi faire ; sinon, vérifiez le statut en ligne de votre service OSS et vos paramètres concernant S3.

1 « J'aime »

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