Ceci n’est appelé que pour les téléchargements sécurisés. Je parie qu’auparavant, vous l’aviez configuré et que vous l’avez supprimé depuis.
Que retourne ceci ?
./launcher enter app
rails c
> Upload.where('secure').count
cc @martin
(Par ailleurs, nous avons un bug de nommage dans site_setting.rb:157:in absolute_base_url. Il devrait s’appeler s3_absolute_base_url.)
Salut Sam,
Merci beaucoup d’avoir jeté un œil à ça !
À ma connaissance, nous n’avons pas activé la fonctionnalité de téléchargement sécurisé. Mais comme je ne suis pas le seul administrateur, je ne peux pas en être certain. Et si je comprends bien, ton comptage devrait retourner 0 si la fonctionnalité n’a jamais été activée ? Eh bien, c’est bien plus que 0 
235 en fait 
Cela retourne :
[1] pry(main)> Upload.where('secure').count
=> 235
[2] pry(main)>
Y a-t-il quelque chose que je puisse faire pour régler ça ?
Devrais-je désactiver le paramètre secure media allow embeded images in emails ?
Vaut-il la peine d’essayer d’activer secure media puis de le désactiver ?
Merci beaucoup pour ton aide ici !
Si vous n’avez pas actuellement la fonctionnalité Média sécurisé activée, vous n’avez pas besoin de l’activer. Elle a dû être activée à un moment donné en raison du nombre de téléversements sécurisés que vous avez. Essayez d’exécuter la tâche rake uploads:secure_upload_analyse_and_update ; celle-ci parcourra tous vos téléversements et les marquera comme sécurisés ou non sécurisés en fonction des paramètres du site (si vous avez désactivé le média sécurisé, ils seront tous marqués comme non sécurisés).
Salut Martin,
merci beaucoup. Je vais essayer cela ce soir.
Juste pour être sûr de bien comprendre. Nous avons actuellement activé :
Devons-nous activer cette option également ? Ou cela n’a-t-il pas d’impact sur le processus de marquage ?
Et pour être tout à fait clair, après la commande rake, dois-je reconstruire l’application ? Ou cela n’est-il pas nécessaire, mais peut-être recommandé ?
Merci beaucoup !
Cette option est activée par défaut, mais elle n’a aucun effet tant que secure media n’est pas activé.
Je ne pense pas qu’une reconstruction soit nécessaire ; je l’ai exécutée sur des sites en production sans aucun problème.
Merci beaucoup !
Je vais essayer et je vous ferai un retour demain.
MERCI MERCI !
Je suppose, mais la trace d’exécution semble indiquer qu’il tente de sérialiser une liste de messages, ou une liste d’informations provenant de messages, et échoue lors de la sérialisation d’une image particulière. L’image est probablement l’image de profil d’un utilisateur. Un seul compte est concerné, il est donc possible que cette image défectueuse appartienne à un utilisateur qui n’a communiqué qu’avec ce compte affecté.
Il est possible que la construction de la liste qui échoue concerne les N messages les plus récents. Peut-être pourriez-vous envoyer N messages (avec des titres de sujets différents) au compte affecté, afin que la liste ne contienne que des messages valides ?
Merci encore pour l’astuce, Martin.
J’ai essayé d’exécuter rake uploads:secure_upload_analyse_and_update, mais le résultat était :
Cette tâche ne fonctionne que pour le stockage externe.
J’ai donc tenté d’activer l’option activer les médias sécurisés. Malheureusement, ou plutôt pour éviter les erreurs de configuration de l’administrateur, cette option ne peut être activée qu’en configurant des buckets Amazon S3. Et je suis absolument certain que personne n’a jamais mis en place une configuration S3 auparavant.
Je ne peux donc pas exécuter le script rake car je n’ai aucun stockage S3 disponible. Je ne peux pas dire si cela a un effet sur pry(main)> Upload.where('secure').count.
Je me demande pourquoi nous avons encore des fichiers uploadés sécurisés alors que nous n’avons jamais activé S3.
Des indices à ce sujet ?
En fait,
Cela a fonctionné. Je suis donc tranquille pour le moment. Même si je n’ai aucune idée de la raison de ce comportement. Je serais ravi d’apprendre quelles autres causes pourraient être à l’origine de ce problème.
Merci d’avance et pour tout le temps que vous avez déjà consacré à cela.
Eh bien Ed_S, que puis-je dire d’autre que
En fait, votre petite astuce a fait l’affaire. J’ai simplement écrit un nouveau message et publié une autre réponse, puis l’erreur a disparu.
Même si vous êtes mon héros pour le moment, cela ne vous exempte pas de futures questions J’espère que vous êtes d’accord pour m’expliquer un peu plus ce qui s’est passé ici.
Tout d’abord, pour mieux comprendre comment lire les journaux. Je veux dire, quelle excellente hypothèse vous avez faite. Qu’est-ce qui vous a poussé à penser qu’un problème de sérialisation était la cause du dysfonctionnement ?
lib/url_helper.rb:90:in `cook_url'
app/models/topic.rb:126:in `image_url'
app/serializers/listable_topic_serializer.rb:34:in `image_url'
Pourquoi pas cook_url ou je ne sais quoi d’autre ?
Deuxièmement, quelles sont vos recommandations ? Dois-je être conscient du risque de rencontrer à nouveau un tel problème ? Ou peut-être avec un autre utilisateur ?
Pensez-vous qu’il existe un moyen d’identifier quel message, utilisateur ou image est le coupable ici ? Y a-t-il une autre façon d’examiner la situation que de… parcourir les messages et espérer avoir un effet sur l’un des messages privés ?
Le plus drôle, c’est que certains administrateurs ont fait exactement la même chose, comme écrire un nouveau message (sujet) au compte concerné, et nous n’avons constaté aucun autre comportement. D’une manière ou d’une autre, le dernier message envoyé par moi au compte concerné a fait l’affaire.
Et enfin, puis-je avoir votre numéro de téléphone pour d’autres appels d’urgence ? Je plaisante !
Mais pour de vrai, merci beaucoup, beaucoup, beaucoup. J’étais vraiment bloqué ici et je suis si content que notre utilisateur – comme je l’ai mentionné, l’un de nos administrateurs – puisse reprendre le cours normal. Merci Ed_S !
Très bonne supposition !
Ha ha – on dirait que j’ai eu de la chance. Ce qui est intéressant avec une pile d’appels, c’est qu’elle va du spécifique au général : ce n’est pas juste une liste d’éléments, mais une représentation des interactions imbriquées, depuis le code général jusqu’aux mécanismes spécifiques. Donc, l’idée de l’image m’a paru pertinente, car il n’y a que des images de profil dans la liste des messages. Et je pense que nous avons déjà rencontré des problèmes étranges avec les images de profil auparavant.
Mais je n’ai aucune idée de pourquoi le code consulte le stockage sécurisé, si vous ne l’avez jamais utilisé.
Je soupçonne qu’une requête de base de données pourrait lister les images qui seraient récupérées dans ce cas, mais je ne sais pas comment vous pourriez identifier le profil fautif. Si, en effet, c’est bien là l’histoire derrière la pile d’appels.
Il existe une tâche rake pour corriger cela :
./launcher enter app
rake uploads:secure_upload_analyse_and_update
Je vous recommande de l’exécuter.
Salut Sam,
merci beaucoup de garder cela sur ta liste. Je suis vraiment ravi de bénéficier d’une aide supplémentaire pour régler ce problème.
J’ai essayé :
Mais en réalité, le même message est apparu : cette commande ne fonctionne que pour les stockages S3 externes. Comme nous n’en avons pas encore configuré, je suis un peu perdu.
Voici ma console :
./launcher enter app
rake uploads:secure_upload_analyse_and_update
This task only works for external storage.
Est-ce que je manque quelque chose ? Ou s’agit-il d’un bug et cela devrait-il fonctionner même avec secure media désactivé ?
Merci pour ton expertise.
En fait, c’est souvent la chance qui nous permet de rester en vie, non ?
Merci quand même. J’étais vraiment un peu frustré, et supprimer tous les messages n’était vraiment que ma dernière option.
Peut-être pourriez-vous m’orienter vers des sujets pertinents ici ? Pour ma part, étant relativement nouveau sur Docker et Discourse, je suis un peu perdu avec votre suggestion d’exécuter une requête SQL. Quelle base de données utilise Discourse ? Puis-je faire quelque chose comme :
./launcher enter app
mysql select bla
Ou s’agit-il de MongoDB ? Mais entrer dans le conteneur et exécuter la requête est au moins la bonne démarche, n’est-ce pas ?
Existe-t-il une liste de champs ou de propriétés que je puisse consulter, comme une référence, afin de pouvoir formuler des idées sur la requête appropriée ?
Juste pour clarifier les choses : même si je parviens à obtenir la liste des images de profil dans la boîte de réception, il n’existe toujours aucune suggestion pour identifier laquelle est celle du « méchant » ni ce qu’il convient d’en faire, même si nous la trouvons, n’est-ce pas ? Avez-vous des idées à ce sujet ?
De plus, je suis surpris qu’il y ait des problèmes récurrents avec les images de profil. Existe-t-il un sujet spécifique que je pourrais lire pour mieux comprendre cela ? Ou peut-être un guide sur la gestion des images de profil, la restriction de leur utilisation ou autre, afin d’éviter ce genre de problèmes ?
Ed_S, merci beaucoup de m’avoir accompagné.
Je ne connais pas grand-chose à la partie base de données, mais je recommande le plugin Data Explorer, qui est officiellement pris en charge, ainsi que ce sujet. (Il est préférable de démarrer un nouveau sujet si vous avez de nouvelles questions : d’autres personnes pourraient en bénéficier grâce au fil de discussion, et un titre de sujet approprié attirera plus d’aide.)
Édité : consultez peut-être aussi
où l’on trouve des indices sur le fonctionnement du mécanisme et sur la manière de l’interroger.
Salut Ed_S,
merci beaucoup pour les conseils. Le plugin Data Explorer est génial ! Pour toute analyse ultérieure, c’est un excellent point de départ !
L’astuce concernant les avatars perdus était également utile. Je l’ai vérifiée et tout semblait correct. Merci encore d’avoir partagé ces informations.
Pour l’instant, tant que ça fonctionne, je suis très content. Je croise les doigts pour que ça dure
Encore merci, Ed_S, pour ton aide précieuse.
Si quelqu’un d’autre tombe sur une telle erreur, n’hésitez pas à me dire ce que vous avez constaté ou ce qui pourrait être fait pour éviter ce genre de problèmes.
Merci à tous d’avoir lu.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.