🚲 Tanguy Ortolo a écrit 12252 commentaires

Avec un openid ouvert

Si vous ne voulez pas d'un truc ouvert et que vous préférez un truc fermé, il ne faut pas aller crier que vous aimez l'ouverture.

il faut vérifier l'email d'office

Vous avez déjà le code pour le faire, puisque vous proposez aussi des comptes locaux basés sur l'adresse électronique, non ?

prévoir un changement de l'URL du provider

Pourquoi ? S'il en change, c'est son problème, pas le votre.

empêcher Kevin de changer le provider d'un autre compte

Je ne comprends pas le sens de cette phrase.

Mais il t'ont fait quoi MicroMou ? :)

Moi j'ai une raison de leur vouloir : je suis leur client. Alors que je n'ai aucune raison de l'être.

• est ce que vous en voulais à LibO de permettre de créer des fichier OOXML ?

Je ne vois pas le rapport

• pourquoi je ne trouve pas dans la page "suivi" de linuxfr, une entrée sur l'authentification OpenID ? On est pas du genre à se revendiquer libriste ici ?

Qu'un service ne propose qu'un mécanisme d'identification interne ne me choque pas. Qu'il propos un mécanisme externe privilégiant artificiellement un prestataire de services, et plus encore, ignorant les autres prestataires du même service, ça me choque.

Eh bien si c'est pour ça tant mieux, ça fait une bonne raison de fuir ce genre de site.

Bah, la plupart des gens donnent leur numéro de carte bleue à un site lambda, or avec le numéro de carte bleue, on peut leur prendre de l'argent. Alors qu'avec leur numéro de CNI, on peut faire quoi au juste ?

Excellente question, je crois que c'est ça le vrai problème. Pourquoi vouloir empêcher à tout prix les comptes de complaisance ?

Est-ce parce que les requêtes sur la base d'informations de la SNCF coûtent de l'argent et qu'ils veulent éviter les abus ? Quel genre d'abus ? Je n'en vois qu'un seul, les utilisations automatisées alors que ce n'est pas censé être fait. Qui se livrerait à ce genre d'abus ? Des gens qui s'y connaissent, assurément. Des gens que la nécessité d'avoir une adresse électronique ou un compte Facebook n'arrêteront de toute façon certainement pas.

tu peux t'authentifier aussi avec login/pass (que tu auras avec ton adresse email) aussi.

Ça tombe bien, ça c'est complaisant. Des adresses électroniques, j'en ai presque une infinité à ma disposition.

Peux-tu proposer une API d'authentification qui vaille la peine d'être implémentée sur un tel site ? Contraintes : bonne part de marché en France ; représenté dans la population adulte générale ; relatif contrôle contre les identités.

Il doit bien y avoir un moyen de faire quelque chose avec OAuth en validant l'adresse par envoi d'un message de confirmation, non ?

Et sinon, quel est le problème avec OpenID au juste ? Les fournisseurs complaisants ? Suffit de les bloquer lorsqu'ils abusent…

D'une part, la possession d'une CNI n'est pas obligatoire en France.

Un compte Facebook non plus. Ceci n'est donc pas un argument de comparaison valable.

Ensuite, si tu commences à demander une CNI, tu vas être légalement tenu d'accepter les documents officiels des 27 États-Membres de l'UE (tu ne peux faire un refus de vente en raison de la nationalité d'un ressortissant d'un autre État-Membre).

Pourquoi ? Faire un refus de vente parce que le client potentiel n'a pas signé de contrat avec une boîte externe, ce n'est pas semblable ? Hop, argument de comparaison invalidé également.

Tu peux très bien décider d'utiliser l'authentification Facebook pour le 2ème avantage sans le premier.

Ou alors tu peux décider d'utiliser OpenID, que Facebook fournit, comme ça tu as aussi le 2ème avantage, en mieux.

Tu as bien vu qu'ils ne requièrent aucun service externe, ils supportent (entre autres) l'authentification par un système externe.

Oui, c'est mon second cas. Ce n'est pas inadmissible, mais c'est détestable.

Note que 1) une part très significative des clients potentiels est constituée de gens qui ont un compte facebook ;

Et ? Ils ont déjà codé la prise en charge OpenID…

2) il n'y a pas foule d'autres systèmes, et openID a au moins le grave défaut cité plus haut (comptes factices trop faciles à créer).

Ça, c'est par conception, OpenID est avant tout au service de l'utilisateur. Si le but est d'interdire à quelqu'un d'avoir plusieurs comptes, c'est sa carte nationale d'identité qu'il faut lui demander, OpenID n'est pas fait pour ça.

Mais dans la vraie vie, ceux qui décide d'utiliser OpenID, c'est les concepteurs de site web. Eux n'ont pas d'intérêt d'intégrer OpenID : - Aucune information intéressante à récupérer. - Peu répandu.

Ça tombe bien ça, OpenID n'est pas fait pour récupérer des informations sur les gens, juste leur fournir un moyen de s'identifier.

Facebook il t'offre sur un plateau des millions d'utilisateurs et des données associées.

Alors je suis content de boycotter ce genre de site web, même s'ils fournissent un moyen alternatifs : si c'est pour récupérer des informations sur les gens qu'ils utilisent Facebook, ça prouvent qu'ils cherchent à tirer profit d'informations personnelles, et je ne veux pas avoir affaire à ce genre de boîte.

C'est toujours ce que je constate chez certains libristes, c'est le manque d'ouverture d'esprit, qui au final (et selon moi) fait plus de mal que de bien

Oui en effet, je suis tellement fermé d'esprit que je critique les sites qui refusent les systèmes ouverts (OpenID en l'occurrence) pour leur préférer des systèmes fermés (Facebook). Surtout quand ils ont codé la prise en charge des systèmes ouverts mais l'ont retirée par la suite.

PS : Pour info, openid n'est pas une technologie Linuxienne

Non, c'est une technologie d'extrémistes qui pensent qu'il est mieux qu'un service puisse être rendu par qui veut plutôt que par une entreprise unique.

Je trouve que ta réaction sur "ils proposent l'authentification via Facebook, je boycotte" est un peu exagérée, parce que tu peux toujours bloquer tout ce qui provient de *.facebook.com , le site continue à fonctionner sans perdre en fonctionnalités.

Ce n'est pas ce que je leur reproche. Ce serait plutôt : ce site web favorise artificiellement Facebook parmi ses concurrents, donc je boycotte. Comme un service d'information qui proposerait au choix d'utiliser une adresse chez Google Mail ou d'en ouvrir une chez eux : je boycotte.

Pour moi, dans l'ordre :

• requérir l'utilisation d'un service externe particulier : inadmissible ;
• requérir l'utilisation d'un service externe particulier ou d'un service interne (donc moins pratique) : détestable ;
• requérir l'utilisation d'un service externe générique, et en suggérer un particulier (donc le favoriser) : désagréable mais acceptable ;
• requérir l'utilisation d'un service externe générique sans en privilégier : parfait.

Ah, j'ajouterai que personnellement, un site qui demande une identification Facebook, même avec au choix la création d'un compte local, je boycotte. Je n'aime pas qu'on privilégie sans raison un acteur unique.

Pour le login Facebook, c'est pas obligatoire, il y a aussi une inscription classique. Il faut savoir que la majorité des gens préfèrent la simplicité de l'authentification déportée Facebook (ie. pas encore un enième mot de passe à retenir...).

C'est sûr, c'est plus simple de faire de Facebook le garant de l'identification de tout individu.

Mais bon, sinon vous avez OpenID…

De mon point de vue, les logiciels doivent toujours trouver un node qui n'a pas de NAT ou utiliser STUN

Non. Passer par des relais, c'est ce que fait Skype, et il suffit pour que ça marche d'avoir un relais qui a déjà transpercé son NAT éventuel.

OSEF. Si tu te soucie de ta liberté, tu n'achètes pas volontairement un produit conçu pour te priver de liberté, même s'il y a des moyens de contourner ces restrictions.

Et donc si au final, SASL external et Dialback ont tout à voir.

Non. Avec TLS + SASL external, tu as une preuve que le serveur qui te contacte a bien le droit de porter le nom qu'il annonce, et c'est tout. Ça ne l'empêche pas d'envoyer du spam sans en prendre le responsabilité, c'est à dire sans permettre qu'on le contacte pour répondre.

Avec dialback, pour pouvoir émettre on doit être joignable dans l'autre sens.

Dans la vraie vie, TLS + SASL EXTERNAL ça donnerait quelque chose comme ça :

• « Bonjour, je suis M. Planet, de la Société Générale.
• Ok, faites voir vos papiers, moi je vous montre les miens et on va se mettre à l'abri des écoutes. [échange de papiers]
• Donc, je disais, je suis M. Planet, de la Société Générale.
• Identifiez-vous, par exemple en disant que c'est déjà fait.
• C'est déjà fait.
• Ok, on peut continuer.

Les trois dernières étapes ont l'air parfaitement surréalistes et inutiles… :-)

Bon, renseignements pris, TLS external ça n'existe pas, il s'agit de TLS + SASL EXTERNAL.

S2S dialback est un mécanisme permettant à un serveur recevant une connexion de la part d'un autre de vérifier que celui-ci est joignable au nom de domaine qu'il prétend représenter :

1. le serveur 1 se connecte au serveur 2, et se présente comme example.com ;
2. le serveur 2 lui répond « dialback » et le met en attente ;
3. le serveur 2 se connecte à example.com — qui est normalement le serveur 1, ou en relation avec lui dans le cas d'un service rendu par plusieurs serveurs en lien — et y envoie un identifiant secret ;
4. le serveur 1 reçoit normalement cet identifiant et le transmet à serveur 2 sur sa connexion existante ;
5. le serveur accepte de continuer.

Ce système est inspiré d'une précaution qu'on peut prendre au téléphone, quand on reçoit un appel d'un inconnu :

• « Bonjour, je suis M. Planet, de la Société Générale, je vous téléphone à propose de votre compte courant… »,
• Attendez une seconde, je vous rappelle — et là, on cherche le numéro de la Société Générale dans l'annuaire et on les appelle pour vérifier qu'ils ont bien un M. Planet.

SASL EXTERNAL maintenant, c'est un pseudo-mécanisme d'identification, qui indique que l'identification a en fait déjà été faite par un autre moyen, ici TLS. En gros ça doit donner quelque chose comme :

1. le serveur 1 se connecte au serveur 2 ;
2. ils mettent en route une session TLS qui permet au serveur 1 de s'identifer avec un certificat à son nom ;
3. le serveur 2 exige une identification SASL, et suggère le mécanisme EXTERNAL ;
4. le serveur 1 choisit le mécanisme EXTERNAL, et ne s'identifie pas du tout puisque ce mécanisme signifie que c'est déjà fait ;
5. le serveur 2 accepte de continuer.

Donc ça n'a strictement rien à voir avec S2S dialback, puisque ça ne répond pas au même problème. S2S dialback, ça fait implicitement confiance au réseau et ça permet de vérifier la responsabilité d'un nom de domaine : quelqu'un me contacte en se présentant comme example.com, est-ce qu'il est vraiment joignable à ce nom-là ou est-ce que c'est un sale spammeur qui ne prend pas la responsabilité de ce qu'il envoie ? SASL EXTERNAL, ça ne sert à rien en tant que tel, ça délègue tout à TLS qui permet de vérifier l'identité d'un nom de domaine, pas sa responsabilité : quelqu'un me contacte en se présentant comme example.com, est-ce que c'est vraiment example.com — qui pourra tout à fait être malgré tout un spammeur irresponsable ?

Soit dit en passant, je ne comprends pas l'intérêt de SASL EXTERNAL. TLS, ok, ça sert, mais à quoi cela peut-il bien servir pour un serveur d'exiger que son correspondant fasse semblant de s'identifier avec un mécanisme qui indique juste que c'est déjà fait ? Comme la session TLS est déjà établie, si ça ne lui convient pas il a déjà eu l'occasion de la refuser…

le système historique et extrêmement faillible d’identification des entités en S2S (server to server), Server Dialback Protocol, est rétrogradé au rang de d’extension XEP, gardant ainsi la compatibilité avec les systèmes anciens, tout en mettant l’accent sur TLS external (qui devient une technologie obligatoire à implémenter en S2S).

Je n'ai pas trouvé de description de ce « TLS external ». De quoi s'agit-il au juste ? À la lecture de cette dépêche j'ai l'impression que c'est la le changement le plus important, et de très loin.

Il faut bien évidemment installer CUPS sur le nouveau serveur. Puis migrer sa configuration /etc/cups/ :

• cupsd.conf : la configuration du serveur lui-même — sur quoi il écoute, comment il s'annonce, tout ça ;
• printers.conf : les définitions des imprimantes ;
• classes.conf : les définitions des classes d'imprimantes, si tu les utilises ;
• ppd/[imprimante.ppd] : le pilote pour chaque imprimante.

Les imprimantes non PostScript utilisent des PPD qui ne sont pas autonomes mais décrivent la commande à utiliser pour produire le raster, donc il faut veiller à installer les programmes requis. Ensuite, redémarrer CUPs et puis c'est tout.

Excuse-moi, mais quelqu'un qui achète volontairement un iPhone ne peut pas être préoccupé par sa liberté. Parce que s'il l'était, il serait renseigné, et saurait que cet ordinateur de poche est fait pour restreindre la liberté de l'utilisateur.