J'ai un petit (mais pratique) plugin, nommé "openid_delegation", qui
ajoute les champs qui vont bien à la table auteurs et qui déclare les
bons headers HTML pour que la page d'un auteur puisse être utilisée
comme adresse OpenID, via le mécanisme de délégation.
A priori c'est un besoin indépendant de l'authentification OpenID sur
le site SPIP en lui-même, mais avec marcimat on s'est dit que
effectivement quand on veut le premier on veut a priori le second, et
vu qu'ils partagent un champ, le plugin "openid_delegation" dépend de
"openid".
La question que je me pose, c'est où l'uploader dans la hiérarchie:
1. dans _plugins_ ?
2. dans _plugins_/authentification ?
3. dans _plugins_/authentification/openid ?
A priori pas 2, car ce n'est pas un mécanisme d'authentification.
Je pense que ça aurait du sens que ce soit un "sous-plugin" de openid,
et que par exemple il soit inclus dans le zip, un peu comme "champs
extras 2" et ses sous-plugins, mais je ne sais pas trop comment faire.
J'ai essayé l'option 3 en local, mais l'interface des plugins ne le
reflète pas correctement.
J'ai un petit (mais pratique) plugin, nommé "openid_delegation", qui
Tu aimes la complication, entre le sous-plugin pour gravatar/havatar et ça
Pourquoi ne pas l'ajouter directement dans le plugin openid ? Le fait
qu'il ne gère pas la délégation est clairement de l'ordre du bug, en
tous cas de la "missing feature".
Pourquoi ne pas l'ajouter directement dans le plugin openid ? Le fait
qu'il ne gère pas la délégation est clairement de l'ordre du bug, en
tous cas de la "missing feature".
Je pense que c'est une barrière psychologique : pour moi c'est encore 2
besoins indépendants. Moi idéalement j'aurais bien vu que le champ
"openid" soit déclaré dans son propre plugin, à part, et que autant
openid que openid_delegation le <necessite/>nt :
(a) on peut vouloir permettre aux auteurs que leur page soit une
délégation openid sans pour autant faire de l'auth openid sur le
site
(b) on peut vouloir faire de l'auth openid mais s'en foutre (ou être
contre) de fournir une délégation de la page auteur vers leur openid
"réel".
Mais il est probable que plus aucun autre plugin n'ait jamais besoin de
ce champ, du coup faire un 3e plugin serait overkill pour l'instant
(on verra plus tard si le besoin apparaît). Par ailleurs d'après
marcimat: (!a) si on veut de la délégation de la page auteur, on veut
probablement de l'auth openid sur le site. Ça me paraît toujours pas si
évident, mais soit. Maintenant toi tu dis aussi: (!b) si on veut de
l'auth openid, on veut pouvoir fournir de la délégation.
Du coup je crois que je bloque encore sur l'idée que l'un implique
forcément l'autre, mais ça va venir. D'ailleurs dans ton sens ça me
va beaucoup plus car c'est un ajout léger ; c'est toujours à (a) que
j'ai du mal à renoncer.
> c'est toujours à (a) que j'ai du mal à renoncer.
fais-en une option de configuration ? " Proposer la connexion via
openid"
Oui... mais c'est un peu absurde de proposer une option de configuration
pour zapper 99% du plugin, c'est-à-dire tout un mécanisme
d'authentification, et garder le 1% restant qui consiste en un champ
auteur + un modèle, non ?
fais-en une option de configuration ? " Proposer la connexion via
openid"
Oui... mais c'est un peu absurde de proposer une option de configuration
pour zapper 99% du plugin, c'est-à-dire tout un mécanisme
d'authentification, et garder le 1% restant qui consiste en un champ
auteur + un modèle, non ?
Je préfère ça plutôt que devoir installer trois plugins, pour ma part...
fais-en une option de configuration ? " Proposer la connexion via
openid"
Oui... mais c'est un peu absurde de proposer une option de configuration
pour zapper 99% du plugin, c'est-à-dire tout un mécanisme
d'authentification, et garder le 1% restant qui consiste en un champ
auteur + un modèle, non ?
L'avantage est d'avoir tout dans un même plugin destiné à l'identification openid et les protocoles adjacents. Si à chaque 'option', même si elle diffère d'une autre option dans son protocole, on doit créer un nouveau plugin, les forces sont éparpillées.
De plus, pour un utilisateur "lambda" qui désire l'openid sur son site voir une 10aine de plugin différent pour l'openid ne s'y retrouvera pas...
L'avantage est d'avoir tout dans un même plugin destiné à
l'identification openid et les protocoles adjacents. Si à chaque
'option', même si elle diffère d'une autre option dans son
protocole, on doit créer un nouveau plugin, les forces sont
éparpillées.
D'un côté, s'authentifier sur le site avec son OpenID. De l'autre,
bénéficier d'une délégation, c'est-à-dire que l'#URL_AUTEUR puisse
être utilisée *ailleurs*, sur internet, comme identifiant OpenID.
Ce ne sont pas des "options" qui diffèrent dans leur protocole :
ce sont deux choses qui n'ont strictement rien à voir.
C'est un peu comme si toutes les fonctionnalités de "Champs Extras 2"
étaient collées dans un seul et même plugin, et qu'on doive choisir
dans la configuration "désactiver l'interface graphique de gestion
des champs". Au lieu de ça, pas moins de 5 plugins séparés, y compris,
luxe, des plugins d'exemple ! En revanche, on installe le seul et unique
"Champs Extras 2", et dans l'interface de gestion des plugins il y a
plusieurs cases à cocher suivant ce qu'on veut activer.
Voilà ce que j'aimerais, et ma question est: comment faire ?
