discourse(prod)> TopicEmbed.find_by(topic_id: 157441).as_json
La sérialisation des modèles ActiveRecord (TopicEmbed) sans spécifier les champs n'est pas autorisée. Utilisez un Serializer, ou passez l'option :only à #serializable_hash. Plus d'infos : ``https://meta.discourse.org/t/-/314495
=>
{“id”=>56685,
“topic_id”=>157441,
“post_id”=>483289,
“embed_url”=>
“``https://tecnoblog.net/noticias/paramount-oferece-us-108-bilhoes-em-dinheiro-para-tomar-warner-da-netflix”``,
“content_sha1”=>nil,
“created_at”=>“2025-12-08T17:54:07.585Z”,
“updated_at”=>“2025-12-09T18:04:33.539Z”,
“deleted_at”=>nil,
“deleted_by_id”=>nil,
“embed_content_cache”=>“”}
discourse(prod)>
Pourriez-vous simplement exécuter à nouveau la même commande, mais cette fois :
./launcher enter app
rails c
TopicEmbed.find_by(topic_id: 157441).embed_url
Si ce que vous avez partagé est bien la valeur de embed_url dans votre base de données, alors c’est le problème, et je ferai une petite PR vers discourse/discourse pour gérer les cas limites comme celui-ci où l’embed_url s’est retrouvé dans un état mal formé.
Donc, tout ce problème vient du fait que la PR ci-dessus a commencé à supprimer les barres obliques finales de TopicEmbed en janvier de cette année ? Je suis partagé à propos de ce changement. Je préférerais que nous respections ce que l’administrateur nous envoie pour être honnête.
Je pense que c’est la racine de nos problèmes.
Pouvez-vous s’il vous plaît exécuter ce qui suit @Thiago_Mobilon
url = "https://tecnoblog.net/noticias/governo-renova-app-da-cnh-para-baratear-obtencao-do-documento"
fd = FinalDestination.new(url, validate_uri: true, max_redirects: 5, follow_canonical: true)
uri = fd.resolve
puts uri
html = FinalDestination::HTTP.get(uri)
puts html.truncate(200)
Le fd.resolve devrait être capable d’ajouter la barre oblique finale sur la ligne puts uri. J’ai peur que cela échoue.
Il ne suit effectivement pas les redirections. Le forum fonctionne-t-il sur le même serveur / espace IP que le blog ? Cela pourrait déclencher notre protection SSRF.
Si tel est le cas, vous devez l’autoriser via le paramètre allowed_internal_hosts.
La raison pour laquelle nous avons effectué ce changement est qu’il y avait une incohérence entre le fonctionnement des intégrations WP Discourse et des intégrations javascript. Les intégrations javascript normalisaient toujours l’URL. Les intégrations WP Discourse arrivaient par une route différente et ne normalisaient pas l’URL (jusqu’à ce que nous fassions le changement). Cela a entraîné d’autres incohérences.
Un autre problème est que, lorsque j’exécute un curl vers l’API, en recherchant l’ID de sujet d’une URL d’intégration (embed URL), je ne peux pas le trouver à cause de la barre oblique finale (trailing slash). Discourse renvoie une page 404.
Mais si je supprime la barre oblique finale, il renvoie la valeur :
Pour que cela fonctionne, je devrais effectuer un remplacement de chaîne (str replace) dans WordPress, pour supprimer la barre oblique finale du permalien, avant de vérifier. Mais cela n’a aucun sens, l’URL canonique a la barre oblique finale…
En pratique, Discourse normalise le permalien vers une URL qui n’existe pas… la version normalisée devrait être celle avec une barre oblique finale.
Mais je suis toujours préoccupé par les URL sans la barre oblique finale, pour les raisons mentionnées dans mon message précédent. Dois-je ouvrir un nouveau sujet à ce sujet @angus ?
Bien sûr ! Cela n’affectera pas la fonctionnalité “Message complet” car nous pouvons désormais suivre les redirections sur les sites du même domaine que le forum, mais vous pouvez poursuivre dans un nouveau sujet pour toute autre préoccupation.