Les lettres majuscules dans le nom d'utilisateur cassent la vérification des mentions accessibles dans le compositeur

thoka · Avril 22, 2026, 7:47

En enquêtant sur Private Topics Plugin - #109 by thoka, j’ai découvert qu’une mention d’un utilisateur dans une catégorie restreinte n’est pas signalée lorsque le nom d’utilisateur contient des lettres majuscules.

Si je mentionne @SomeUser, l’éditeur effectue une requête vers
/composer/mentions.json?names[]=SomeUser&topic_id=10728
Dans le résultat, le nom d’utilisateur est renvoyé en minuscules, sans que user_reasons soit défini.

Une requête pour le nom d’utilisateur en minuscules renvoie "user_reasons": {"someuser":"category"}.

Si j’utilise des lettres minuscules pour les noms d’utilisateur dans le compositeur, des avertissements sont affichés pour les personnes ne disposant pas de droits suffisants.

Si l’on utilise la saisie semi-automatique fournie par l’éditeur, les noms d’utilisateur en minuscules saisis sont remplacés par des noms en majuscules et ne sont donc pas signalés.

RGJ · Avril 22, 2026, 9:26

Bonne trouvaille @thoka !

Le problème se trouve ici

github.com/discourse/discourse

app/controllers/composer_controller.rb

main


      
                raise Discourse::InvalidParameters.new(:allowed_names)
              end
              params[:allowed_names] << current_user.username
            else
              []
            end
          
          user_reasons = {}
          group_reasons = {}
          @names.each do |name|
            if user = users[name]
              reason = user_reason(user)
              user_reasons[name] = reason if reason.present?
            elsif group = groups[name]
              reason = group_reason(group)
              group_reasons[name] = reason if reason.present?
            end
          end
          
          if @topic && @names.include?(SiteSetting.here_mention) && guardian.can_mention_here?
            here_count =

users retourne {"username_lower" => objet User }

Cependant, si name n’est pas en minuscules, users[name] n’existe pas.

Correction :

if user = users[name.downcase]
...
elsif group = groups[name.downcase]
...

Ou mieux : mettez tous les noms en minuscules au début de la méthode, car il y a beaucoup de problèmes. groups utilise correctement .where("lower(name) IN (?)", @names.map(&:downcase)), mais des fonctions comme visible_group_ids_for_allowed_check, topic_allowed_group_ids, mentionable_group_ids et members_visible_group_ids utilisent toutes where(name: @names), ce qui introduit également des problèmes de sensibilité à la casse.

zogstrip · Avril 23, 2026, 8:34

La correction appropriée se trouve ici :

github.com/discourse/discourse

DEV: Use ActiveRecord normalizes for username lookups (#37177)

main ← fix/unicode-username-lookups

closed 02:15AM - 14 Apr 26 UTC

ZogStriP

+159 -164

Leverages Rails' built-in `normalizes` feature to handle username normalization …consistently throughout the codebase. When you call `User.where(username_lower: value)` or `find_by(username_lower: value)`, ActiveRecord now automatically normalizes the input value. Key changes: - Adds `normalizes :username` (unicode normalize) and `normalizes :username_lower` (unicode normalize + downcase) to User - Adds `normalizes :email` (strip + downcase) to UserEmail - Removes manual `.downcase` and `.map(&:downcase)` calls before AR queries - Adds `User#matches_username?` method for comparing usernames - Simplifies `filter_by_username` and `filter_by_username_or_email` scopes to use `ILIKE ANY(ARRAY[?])` instead of branching on array vs single value - Updates `filter_by_username` to normalize input for ILIKE patterns - Updates `find_by_username` to rely on AR normalization - Fixes a SQL injection vulnerability in search user ordering - Uses before_save callback for username_lower assignment to ensure it runs even when validation is skipped (e.g., finish installation flow) - Adds shoulda matcher tests for username normalizations The `normalize_username` class method is kept for cases where AR can't help: raw SQL queries, ILIKE patterns, and direct comparisons. Ref - https://meta.discourse.org/t/393646

mais c’est un changement trop important pour que je me sente à l’aise de le fusionner à ce stade

À la place, je vais corriger chaque « endpoint » un par un afin de simplifier la revue et de réduire les risques.

Voici la première étape :

github.com/discourse/discourse

FIX: Make composer mention reachability checks case-insensitive (#39482)

main ← fix-composer-mention-case-sensitivity

opened 08:30AM - 23 Apr 26 UTC

ZogStriP

+200 -190

Mentioning `@SomeUser` in a topic the mentioned user can't see (restricted categ…ory, PM they aren't invited to, topic they've muted) silently skipped the "cannot see this mention" warning popup whenever the typed name contained any uppercase letter. Same for mixed-case group names. Mention validation itself worked because of an existing client-side `.toLowerCase()` workaround, so the bug was easy to miss — mentions stayed `<a class="mention">` but the user got no signal that the mentioned account wouldn't actually be notified. Server side, `ComposerController#mentions` builds its `users` lookup keyed by `username_lower` and `groups` keyed by the case-preserved DB `name`, then iterated `@names.each { |n| users[n] || groups[n] }` without normalizing — so any uppercase character missed both hashes and `user_reasons`/`group_reasons` came back empty. Four downstream group helpers (`mentionable_group_ids`, `members_visible_group_ids`, `topic_allowed_group_ids`, `visible_group_ids_for_allowed_check`) used `where(name: @names)` which is case-sensitive in PostgreSQL, and the `SiteSetting.here_mention` membership test compared raw strings. Client side, `link-mentions.js` cached `foundUsers` / `userReasons` / `foundGroups` / `groupReasons` by the case as typed, and the prosemirror `mention.js` warning lookup did `response.users.includes(name)` plus `response.user_reasons[name]` with the original case — both of which the server only ever returned in the casing it had on hand. Normalize the controller's `@names` and `@allowed_names` once at the top of the action, switch all four group helpers to `LOWER(name) IN (?)`, lower-case the response keys, and lower-case client caches and lookups end to end. Also extract the inline notified-member query into `already_notified_member_count` and tighten the request specs to cover users, mentionable groups, group reasons in PMs, and `allowed_names` (both user and group branches) with mixed-case input. https://meta.discourse.org/t/401292

Ethsim2 · Mai 13, 2026, 3:03

Depuis la reconstruction de Discourse pour les 188 commits allant de 645cb014c0 à 102c93e2ea, j’ai remarqué une nouvelle régression dans l’éditeur Markdown.

Cette fenêtre contextuelle ne signifie rien, mais elle apparaît à chaque fois que j’essaie d’interroger mon agent personnalisé @Forum_Research_Assis.

Je parviens à reproduire ce problème de manière constante, comme le montre la vidéo de reproduction :

Je pense que ce même commit manque de logique pour contourner le cas où l’utilisateur mentionne un agent IA.

Je suis prêt à lancer une autre demande de tirage (pull request) quand vous serez prêt, bien que j’en aie déjà une ouverte sur mon seul compte GitHub.

zogstrip · Mai 13, 2026, 4:25

Il semble que mon « correctif » ait révélé ce problème pour les agents IA

github.com/discourse/discourse

FIX: Suppress composer mention warning for AI bot users (#39986)

main ← fix-composer-mention-warning-ai-bots

opened 04:24PM - 13 May 26 UTC

ZogStriP

+85 -1

Mentioning an AI bot (e.g. `@Forum_Research_Assis`) in a topic the bot's User re…cord can't see — like a category restricted to a group the bot isn't part of — surfaced the "this user cannot see this mention" warning popup in the composer. The warning is misleading: AI bots reply via `PostCreator.create!(... skip_guardian: true)` (`playground.rb`), so they respond regardless of whether their User can `Guardian#can_see?` the topic. The previous case-insensitive fix (9a4cca29) exposed this latent behavior. Pre-fix, mixed-case names hit a case-sensitive hash miss in `ComposerController#mentions` and silently returned an empty `user_reasons`. Post-fix, the lookup hits correctly and the reachability check — which was always there — now fires for AI bot users that genuinely can't see the topic. Adds a `:composer_mention_user_reason` plugin modifier, applied after the standard reason is computed in `user_reason`, so plugins can clear or transform it. The AI plugin registers against the modifier and returns `nil` for any user in `DiscourseAi::AiBot::EntryPoint.all_bot_ids` (covering both AI agent users and chat-bot-enabled LLM model users). discobot and the system user are intentionally unaffected: discobot's `PostCreator.create!` does not skip the guardian, so the reachability warning remains accurate for it. https://meta.discourse.org/t/401292

Sujet		Réponses	Vues
Rich editor misses usernames with umlauts Bug composer	4	218	Août 1, 2025
Preview is changing casing of @ mentions Bug	2	894	Juin 15, 2015
Discobot case-sensitive mentions Bug	3	615	Mai 7, 2019
Unicode username with Σ as the final char leads to an error loading profile page Bug	36	2346	Février 23, 2021
Highlighting current user and bots in posts UX feedback , design-experiment	3	161	Mars 19, 2026

Les lettres majuscules dans le nom d'utilisateur cassent la vérification des mentions accessibles dans le compositeur

Sujets connexes