Le 11/08/2013 à 00h 46

animus a écrit :



Moi, ce qui m’intrigue, c’est qu’il est marqué partout que c’est “décentralisé”, mais je ne vois pas comment (si?) on peut auto-héberger la solution sur un serveur perso, sans avoir à passer par les serveurs de Mozilla, si l’interface ne propose pas une “url” pour se connecter, à l’image d’openId.





Pour avoir un peu lu la doc technique, c’est décentralisé jusqu’à ton fournisseur de mail.

Il faut que celui-ci devienne IdP (Identity Provider).

Concrètement, quand tu tentes de t’authentifier via Persona, ton navigateur va tenter de contacter une page spécifique de ton fournisseur de mail, définie par mozilla (par exemple, si ton adresse est [email protected], ton navigateur tentera de joindre http://unserveurmail.com/.well-known/browserid ).

Si l’URL existe et a un résultat valide, alors c’est ton serveur de mail qui prend le relai, et va te demander de t’authentifier. Une fois fait, celui-ci enverra la confirmation au service où tu tentes de te connecter ou t’inscrire.



PS : désolé pour le double post.

Le 11/08/2013 à 00h 39

David_L a écrit :



Tout le souci c’est qu’il faudrait que tous les navs se mettent d’accord sur le sujet… et pour le moment, Mozilla fait ça dans son coin.>





Sur ce point, je suis d’accord, il serait intéressant que cela soit implémenté selon un standard. Le soucis, c’est que les navigateurs d’en face n’ont aucun intérêt à implémenter un système respectueux de la vie privée.

Connaissant les habitudes de Microsoft et d’Apple, ils ne verraient pas l’intérêt d’implémenter un tel standard libre dans IE et Safari, préférant sans doute développer un système propriétaire basé sur un compte Microsoft/Apple :/







David_L a écrit :



De mémoire, il est surtout prévu que les IDP prennent en charge le login en direct plutôt que le fallback (ou alors que ça passe par les bridges) et que les sites gèrent eux même l’étape de vérification plutôt que de déléguer ça aux serveurs de Moz





Le problème est plus complexe que ça. Comme je le disais, à l’heure actuelle, il est déconseillé d’héberger soit même l’API JS (“Because Persona is still in development, you should not self-host the include.js file”).

Si les serveurs de Mozilla venaient à tomber en panne, le navigateur ne pourrait plus charger le JS de Persona et donc il deviendrait impossible de s’identifier (le navigateur n’ayant plus accès à navigator.id).

De plus, à l’heure où les pages s’alourdissent sans cesse de code JS (pas toujours utile) : entre jQuery, Google Analytics, les modules sociaux, j’en passe et des meilleurs, Mozilla nous propose d’alourdir encore un peu plus tout ça.

Dernière chose, plus embêtant, en se basant sur du code JS, qu’est-ce qui empêche quelqu’un de modifier l’API navigator.id de Mozilla pour venir s’interposer entre le navigateur et l’IdP, pour récupérer d’autres informations (le mot de passe de l’utilisateur, voir plus d’informations, si elles sont affichées à l’écran) ?

Le 09/08/2013 à 23h 27

De mon côté, j’ai hâte que l’idée « originelle » de BrowserID (que dis-je, de “Persona”) soit — enfin — implémentée : une authentification effectuée par le navigateur.



À l’heure actuelle, pour accéder à Persona, il est nécessaire de passer par le script JS de Mozilla, qui était (à l’époque où je m’étais renseigné) impossible à héberger soit même.



De fait, même si votre fournisseur est IdP, vous dépendiez un minimum des serveurs de Mozilla pour vous identifier. Le serveur de Mozilla crashe, et c’est des dizaines (centaines, milliers…) de sites sur lesquels vous ne pouvez plus vous connecter.



À l’origine, BrowserID devait être une API JS intégrée au navigateur, et c’est lui qui devait se charger de contacter l’IdP pour effectuer l’authentification.



Espérons que cette approche soit encore dans les esprits des employés de Mozilla…



(Pour les intéressés, la référence de l’API navigator.id sur MDN telle qu’elle aurait du être implémentée)

Le 07/08/2013 à 18h 30

C’est très bien la double authentification, je l’utilise autant que je peux, mais je n’ai d’une part pas envie de donner mon numéro de portable à Twitter, et je ne veux installer leur client, j’ai déjà mon client Android (Twidere) qui me convient très bien !



Vivement que Twitter suive Dropbox et Facebook et fasse de la double authentification compatible avec Authenticator de Google !



Pourquoi avoir besoin d’un client différent par site pour la double authentification alors qu’il existe une application qui pourrait tout centraliser ?

Le 20/09/2012 à 16h 03

David_L a écrit :



Bizarre, c’était pas limité par pays dans un premier temps ? Parce que j’ai regardé y’a pas si longtemps que ça et ce n’était pas encore proposé de mémoire.





Je ne me souviens pas avoir remarqué cette limitation, et je n’ai pas trouvé d’infos confirmant tes dires.

En tout cas, si c’était géographiquement limité, c’était autorisé en France. En effet, je me souviens très bien avoir remarqué leur statut Facebook en parlant, et avoir comparé les prix au mois et à l’année pour voir la différence sur 1 an.

Le 20/09/2012 à 09h 31

Ah, enfin un article là dessus " />

Non, parce que mine de rien, ça fait quand même plus de 2 mois que l’on peut payer au mois, hein " />

https://www.wuala.com/blog/2012/07/wuala-now-supports-monthly-payments.html