Silverpeas » Silverpeas Core

Effectivement, l'identifiant pour XMPP est récupéré de celui de Silverpeas. Or comme le caractère @ a un statut particulier dans XMPP, à l'image des adresses email, seule la partie précédente au @ dans l'identifiant Silverpeas est récupérée pour former l'identifiant XMPP pour un domaine XMPP donné. Dans XMPP, comme pour les emails, deux personnes peuvent avoir le même identifiant si et seulement si ils ne sont pas du même domaine (parce que l'identifiant complet XMPP est de la forme <identifiant utilisarteur>@<domaine XMPP>).

Est ce que les deux utilisateurs sont du même domaine Silverpeas ? Si non, une astuce est d'associer à chaque domaine Silverpeas un domaine XMPP différent.

Je vais voir en m'inspirant de la suggestion de Yohann pour encoder le arobas dans un identifiant de type mail.

Attention, la correction ici va impacter l'existant. Les Silverpeas avec des utilisateurs qui ont des identifiants au format email vont avoir leur identifiant XMPP modifié, autrement dit un nv compte va leur être créé et tout l'historique sera perdu. Sauf évidemment s'il est possible de modifier leurs identifiants directement dans la base de données utilisée par eJabberd.

Aussi, avant de continuer sur cette voie, je voudrais savoir combien de clients utilisent le chat et combien parmi eux ont un identifiant au format email ?

Cf. PR https://github.com/Silverpeas/Silverpeas-Core/pull/1218

Le format des JID (identifiants XMPP) est régit par la RFC 7622. Le format d'un JID d'un utilisateur est similaire à celui d'une adresse email. Parce que les JID d'un utilisateur de Silverpeas est construit à partir, entre autre, de son login, ceci peut s'avérer être problématique lorsque ce login est une adresse email. La solution adoptée jusqu'alors fut de retirer la partie domaine de l'adresse email (le caractère @ comprit). Or ceci pose problème dans le cas où le domaine de l'adresses email des utilisateurs est différent (autrement dit différent service de mail) et qu'il y a des homonymes. Ce qui s'avère être le cas ici dans ce billet.

Pour palier à ceci, un nouveau mécanisme de conversion de login des utilisateurs est introduit : tout caractères @ est encodé sous sa forme hexadécimale UTF-8 mais en tant que terme et non en tant que codepoint (sinon ça sert à rien). Le choix du mécanisme à utiliser est définit par la propriété chat.xmpp.jid.policy dans le fichiers properties/org/silverpeas/chat/settings/chat.properties. Par défaut, c'est le mécanisme précédent qui est utilisé. Pour le changer et choisir le nouveau mécanisme, il suffit de changer la valeur de la propriété par 1.

Validé et intégré en 6.3