non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.
Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.
Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).
Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible.
2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte.
3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte).
4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...
Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 3.
Salut,
non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.
Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.
Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).
Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible. 2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte. 3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte). 4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...
Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]