Bug #13019
fermé
Impossible de créer un utilisateur si la racine de son idenfiant (avant @) existe déjà
Ajouté par David Lesimple il y a environ 2 ans.
Mis à jour il y a environ 2 ans.
Catégorie:
Messagerie instantanée
Votre version de Silverpeas:
6.3-BUILD
Votre base de données:
Toutes
Description
Pré-requis: il existe déjà un utilisateur avec un identifiant titi
pour lequel Ejabberd a crée dans le domaine XMPP un compte titi@domaine.xmpp
Si je crée un utilisateur avec un identifiant titi@domaine.com
il y a une erreur :
Caused by: org.silverpeas.core.chat.ChatServerException: Conflict: {"status":"error","code":10090,"message":"User titi@domaine.xmpp already registered"}
parce que pour Ejabberd, on extrait la partie avant le caractère @
- Statut changé de New à Feedback
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.
Est-ce qu'une solution pourrait également être de mettre la partie derrière l'@
du login entre crochets [xxx]
?
Par exemple, toto@domain.org
serait transmis au serveur XMPP en toto[domain.org]
.
Miguel Moquillon a écrit (#note-2):
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.
Oui, il n'y a qu'un seul domaine utilisateurs.
- Statut changé de Feedback à In progress...
Je vais voir en m'inspirant de la suggestion de Yohann pour encoder le arobas dans un identifiant de type mail.
- Statut changé de In progress... à Feedback
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 ?
- Statut changé de Feedback à Resolved
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
.
A la demande, j'ai modifié la valeur par défaut de la propriété chat.xmpp.jid.policy
à 1 : désormais, le caractère spécifique @
est encodé pour garder la partie domaine de l'adresse email dans le login
- Statut changé de Resolved à Integration in progress...
- Statut changé de Integration in progress... à Closed
- % réalisé changé de 0 à 100
Formats disponibles : Atom
PDF