Le Emoji Picker n'utilise pas les URLs CDN pour les emojis personnalisés

Bug
1

Description

Les chemins d’émojis standard ne sont pas convertis en URL CDN, tandis que les chemins d’émojis d’administration sont correctement convertis.

Evidence

Contrôleur standard (pas de conversion CDN) :

Contrôleur d’administration (conversion correcte à l’aide d’EmojiSerializer) :

Les chemins d’émojis standard doivent être convertis en URL CDN, tout comme les chemins d’émojis d’administration.

2 « J'aime »
2

Voyez-vous ces URL utilisées quelque part dans l’interface utilisateur ? Je soupçonne qu’elles sont converties en URL CDN dans l’application JS avant d’être affichées.

3

J’ai vérifié et je peux confirmer que les émojis utilisent directement des URL S3 (commençant par //) dans la sortie rendue, et non des URL CDN.

4

Sur quelle page voyez-vous cela ?

5

Vous pouvez le voir sur la page de composition de publication lorsque vous utilisez le sélecteur d’emojis. Lorsque les emojis personnalisés sont chargés, ils utilisent directement les points de terminaison S3, comme :

https://assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/1/d/1de8f76096f76cf393640bdcff387ec9ae33dd3e.gif

Cela montre que les chemins ne sont pas convertis en URL CDN comme prévu.

6

image
image2408×416 228 KB

image
image2002×896 114 KB

7

Test d’emoji personnalisé :awthanks:

:up_arrow: ceci est expédié depuis le CDN S3… Nous avons un problème avec le sélecteur lui-même @j.jaffeux

L'image montre une page de résultats de recherche affichant divers emojis de visage souriant dans une section nommée « SOURIRES ET ÉMOTIONS ». (Légendé par l'IA)
L'image montre une page de résultats de recherche affichant divers emojis de visage souriant dans une section nommée « SOURIRES ET ÉMOTIONS ». (Légendé par l'IA)580×455 70.1 KB

N’utilise pas le CDN S3 pour les emojis personnalisés

Cette interface utilisateur utilise le CDN S3

Cette image montre une capture d'écran d'un menu déroulant de saisie semi-automatique avec le préfixe « badger », listant plusieurs termes suggérés, notamment « badminton », « badpokerface », « supervillain » et « -1 ». (Légendé par l'IA)
Cette image montre une capture d'écran d'un menu déroulant de saisie semi-automatique avec le préfixe « badger », listant plusieurs termes suggérés, notamment « badminton », « badpokerface », « supervillain » et « -1 ». (Légendé par l'IA)403×282 20.4 KB

C’est donc très spécifique au sélecteur d’emojis, amélioration du titre ici.

1 « J'aime »
8

Merci, cela devrait résoudre le problème :

3 « J'aime »
9

Merci pour votre PR qui permet l’utilisation du CDN pour les emojis personnalisés.

Bien que votre correctif frontend demande correctement les adresses CDN des emojis, je suis préoccupé par la sécurité backend.
Le point de terminaison https://meta.discourse.org/emojis.json expose toujours les URL sources S3 comme //assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/6/1/61e481320406f0f82ed780db3f04056128191613.png, ce qui pourrait potentiellement entraîner des abus malveillants et une facturation S3 excessive.

Pour une meilleure sécurité, je suggère de retourner directement les adresses CDN, de manière similaire à la gestion des emojis non personnalisés.

Voici ma tentative de correction du code :

class EmojisController < ApplicationController
  def index
    emojis = Emoji.allowed.group_by(&:group)
    
    emojis.each do |_, emoji_list|
      emoji_list.each do |emoji|
        emoji.url = Discourse.store.cdn_url(emoji.url) if emoji.url.present?
      end
    end
    
    render json: MultiJson.dump(emojis)
  end
  def search_aliases
    render json: MultiJson.dump(Emoji.search_aliases)
  end
end
10

Oui, je sais que nous le faisons directement pour les emojis non personnalisés dans emoji.rb, ce que je préférerais au contrôleur. Je veux m’assurer que cela ne va pas causer de problèmes, j’ai donc apporté la correction la plus simple pour l’instant, mais je creuserai cela à l’avenir.

2 « J'aime »
11

Fermeture car le problème d’origine est résolu, n’hésitez pas à ouvrir une autre demande de fonctionnalité pour le suivi.

Ces ressources sont minuscules et généralement publiques, le risque semble faible.

2 « J'aime »