Concernant le champ futur_username @pierreok le fait de mettre le champ obligatoire pour toutes les applications va clairement poser des conflits d’usage. J’aurais dû en parler sur Framateam pour prévenir les admins. En ajoutant le champ sans prévenir, c’est « normal » qu’un admin ait enlevé l’obligation.
est ce que c’est ce champ qui est utilisé pour le champ futur_username?
Est-ce que c’est possible de mettre un tooltip sur le champ pour expliquer que ça sera l’identifiant qui peut être utilisé par les applications et que si ce n’est pas rempli, ce sera un identifiant généré aléatoirement?
Est-ce que ce futur_username est visible dans l’application (mastodon)? J’imagine le cas ou un futur_username est généré (notamment dans le cas le champ futur_username n’a pas été rempli, car pas obligatoire). Est-ce qu’il peut être modifié dans l’application s’il apparaît ?
Est-ce que ce futur_username, qui va devenir username à terme, est visible dans d’autres applications (nextcloud,…) et va impacter l’ergonomie dans l’application (ne pas pouvoir changer son nom dans l’appli par ex).
Je vais informer les admins des travaux en cours une fois que j’aurais une meilleure compréhension grâce à tes réponses. Je suis disponible par MP et tel pour en parler si besoin.
Un énorme merci pour ce que tu as mis en place. Les communs grandissent !
oui
Le nom technique est « futur_username ».
Le nom pour les users est « Pseudo ».
(C’est un choix un peu arbitraire, qu’on peut changer)
Tout est possible, suffit de modifier votre custom template.
J’ai configuré le SSO sur mastodon pour mapper « futur_username » de keycloak sur le champs « UID » de mastodon.
Pour mastodon, une fois le UID créé, il est immutable.
En effet, c’est le username dans la fédération, et c’est pas facile d’en changer.
Le champs n’est créé que dans Keycloak, et pour qu’il apparaisse dans un client (une application comme Nextcloud) il faudrait que celui ci soit configuré pour. C’est pour cela que j’ai choisit un nom un peu exotique, peu de change qu’une app essaye de chercher « future_username » contrairement à « username », ou « prefferred_name ».
Je retiens 2 options car il y a peu de force pour plonger dans les templates du SSO des communs.
fédération
pas de SSO
La fédération me semble prometteuse. Quand tu dis fédération, est-ce que ça veut dire que le user n’a qu’un user/password à retenir et que son user créé dans le realm commun peut servir dans le realm mastodon?
Si c’est bien le cas, je suis à 100% pour cette solution.
Oui, il faudrait que j’investigue un peu, mais si j’ai votre go, je peux faire cela.
( et en fait, cela pourrait devenir la méthode de transition douce vers un realm par application/communauté, mais bref, sans rentrer trop dans le détails, on va déjà l’expérimenter sur le masto )
Je l’appellerai comment le realm? transition-citoyenne-org ?
plutôt mastodon-transition-citoyenne-org ou mastodon-transition-citoyenne ou communs-username car nous n’avons pas l’aval du CTC pour créer un realm qui leur serait dédié d’autant qu’ils ont déjà un realm avec liiibre.
Pour moi c’est ok à 100% pour tenter la fédération.
Je crois que j’ai une préference pour un realm communs-username qui montre bien de quoi il s’agit et qui pourra être utilisé pour d’autres outils qui ont besoin d’un username, qui forcera les personne qui ont déjà un compte sur https://login.lescommuns.org/ de définir un username sur ce royaume et qui pourra permettre une migration progressive. Et tout cela sans impacter les uages existant
@pierreok, on faisait un point avec Simon ce matin et on se demandait si tu avais besoin d’infos supplémentaires pour avancer ?
On est bien conscient que tu fais tout ça bénévolement, que c’est l’été, toussa, toussa, donc rien ne presse. Juste pour savoir si il manque des infos de notre côté ou juste de la dispo de ton côté ?
sur l’url du keyclaok (la notre par default, qu’on peut changer facilement, meme dans le future)
l’email qui envoie les notif (pareil)
le theme du keyclaok (le notre par defaut, pareil)
Les choses améliorables:
une page d’explication? il faudra le mettre dans le theme
le username mets l’email actuel, c’est le mapping, c’est comme ça j’ai essayé de le changer, sans succès…
Peut-etre désactiver le login local de ce nouveau realm?
Si cela ne fonctionne pas pour vous/votre compte, c’est que le mapping est déjà plus ou moins fait dans mastodon… Je pense qu’il faudrait reset l’instance, mais j’ai pas osé, javais l’impression que vous aviez fait des trucs dessus, un peu.
Je suis en vacances ce soir, mais je re mardi.
En espèrant que cela coche pas mal de cases, je suis en tout cas, personellement assez satisfait du flow.
Si je valide tel quel (pour garder mon mail comme username et matcher mon ancien compte) j’ai un message d’erreur
si je mets simon_louvet comme username, je retourne bien sur mastodon mais j’ai un message d’erreur
Si j’ouvre une session anonyme, et je veux me loguer, tout est cohérent (masto->realm avec username → realm sans user name → authentification → passage invisible par le realm avec username → masto) mais j’ai la même erreur que ci dessus.
Je pense qu’il faut effectivement éviter de pouvoir fair un login local sur ce realm et obliger de passer par login.lescommuns. Nous pouvons mettre un petit template quand on passe par le realm avec username pour expliquer (vous êtes sur une étape intermédaire pour créer votre username à partir de votre compte login.lescommuns…). Je peux contribuer dans ce sens.
Cela évitera des confusions et respectera la logique de login.lescommuns d’avoir un seul endroit pour se loguer.
Si il faut réinitialiser l’instance de mastodon pour résoudre le/les bugs, n’hésite pas. On refera le paramétrage de l’instance et des comptes.
Encore un grand merci pour tout ce que tu fais. Cette architecture/urba entre les 2 realms me semble claire et conviviale si on l’améliore (pas de login locale, template…), permet d’avoir un username pour les applications qui en ont besoin, conserve un seul realm « visible » pour le user. Pas d’impact sur les applis existantes et username pour les applis qui en ont besoin, c’est vraiment top.
Cette solution, que tu as proposée, me semble vraiment l’idéal, car elle permet aux applications existantes qui utilisent le royaume master de ne pas être impactées et axu application qui ont besoin d’un username de migrer.
Est-ce que j’avais mal compris ?
Est-ce que je suis en avance de phase et que c’est dans ton pipe?
Est-ce que tu as besoin de revoir les modalités de coopérations / réciprocité ?
Encore merci pour tout ce que tu as permis de faire. Transiscope est en train de préparer la sortie une fois que on sera clean sur l’authentification.
Pour les curieux de savoir à quoi ca va ressembler, il y a déjà ce fil public : Mastodon
