LinuxFr.org dispose maintenant d'une API Rest au format JSON qui s'appuie sur OAuth2 pour l'authentification. Cette API est encore très limitée (elle ne possède qu'une seule méthode), mais elle s'enrichira en fonction de vos demandes. N'hésitez pas à créer des entrées dans le suivi pour indiquer quelles seraient les méthodes dont vous auriez besoin.
Pour le moment, elle permet à des sites externes d'authentifier un utilisateur à partir de son compte sur LinuxFr.org comme le proposent des réseaux sociaux bien connus. Cela pourrait par exemple servir à des tribunes hébergées sur d'autres sites pour permettre à leurs utilisateurs de se connecter en un clic.
Cela fonctionne avec le standard OAuth2 mais, si vous êtes un développeur Ruby, je vous recommande d'utiliser la gem Omniauth qui permet de mettre en place l'authentification via LinuxFr.org de manière très simple.
Aller plus loin
- Documentation sur l'API (453 clics)
- Enregistrer son application (139 clics)
- Demander une méthode d'API particulière dans le suivi (68 clics)
- Stratégie LinuxFr.org pour la gem Ruby omniauth (47 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
# la question qui fâche
Posté par B16F4RV4RD1N . Évalué à 3.
et pourquoi ne pas utiliser OpenID ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la question qui fâche
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Je ne voudrais pas m'avancer, mais je pense que Bruno s'est basé sur une analyse de marché établie sur des données fiables, vérifiées et brillamment interprétées.
[^] # Re: la question qui fâche
Posté par __o . Évalué à 0.
Avec openid vs oauth, openid gagne :) http://www.googlefight.com/index.php?lang=en_US&word1=openid&word2=oauth
[^] # Re: la question qui fâche
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Ce n'est pas ce que l'image précédente avait de plus remarquable.
[^] # Re: la question qui fâche
Posté par Christophe . Évalué à 10.
De nos jours, sur les jolis graphiques, qui lit les chiffres ? :)
[^] # Re: la question qui fâche
Posté par ecyrbe . Évalué à 2.
Joli bug!
[^] # Re: la question qui fâche
Posté par __o . Évalué à 9. Dernière modification le 11 décembre 2011 à 21:31.
OAuth et OpenID ne servent pas à la même chose.
OpenID c'est pour t'identifier sur des sites externes en utilisant ton compte LinuxFR. L'avantage de OpenID c'est que ça marche sur tous les sites qui supportent OpenID, même si le site en question n'a jamais entendu parler de LinuxFR.
OAuth2 c'est plus pour consommer un service fournis par LinuxFR (l'API, dans ce cas): Un site spécialement conçu pour utiliser l'API de LinuxFR peut utiliser l'API en tant que toi, si tu lui en donne l'autorisation.
Les sites peuvent aussi s'en servir comme moyen d'identification, mais ce n'est pas l'usage premier de OAuth. Au contraire d'OpenID, il faut que le site gère l'identification via LinuxFR explicitement (comme ça se fait avec Twitter et Facebook, qui utilisent OAuth eux aussi).
Donc OAuth c'est bien quand on fournis une API, et OpenID c'est bien quand on veut fournir une identité.
[^] # Re: la question qui fâche
Posté par fredix . Évalué à 3.
Donc l'idée sous-jacente serait de pouvoir troller depuis un site/logiciel tiers comme l'on tweet ? ...
[^] # Re: la question quifâche
Posté par moules . Évalué à 3.
Par hasard, Monboob ?
[^] # Re: la question qui fâche
Posté par Jean B . Évalué à 4.
Oui, si à terme l'API authorize à poster des commentaires etc, alors on pourra développer des clients natifs pour linuxfr.
[^] # Re: la question qui fâche
Posté par Bruno Michel (site web personnel) . Évalué à 3.
C'est effectivement l'idée. Maintenant développer l'API pour faire toutes les actions possibles depuis l'interface web risque de prendre beaucoup de temps, donc si certains ont un avis sur ce qui devrait être fait en premier, je suis preneur.
[^] # Re: la question qui fâche
Posté par VictorAche . Évalué à 1.
La tribune (ok, je sors).
Sérieusement, les fonctions de création de contenu me paraissent les plus importantes, suivies de l'accès au suivi.
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: la question qui fâche
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 2.
Ben c'est pas idiot de commencer par le post dans la tribune : ça permet de se faire les dents sur un truc simple. De plus, les clients existent déjà, les nombreux développeurs de coincoins seront tout heureux d'implémenter cette nouvelle feature !
[^] # Re: la question qui fâche
Posté par YBoy360 (site web personnel) . Évalué à 2.
Ok, alors c'est parti je développe le plugin MS Office 2011. Ça devrait aider certains.
[^] # Re: la question qui fâche
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Je compte développer d'autres méthodes dans cette API (par exemple, pouvoir poster un commentaire) et cette partie à base d'OAuth2 va servir de base pour cela. OpenID ne fait que de l'authentification (et encore assez mal) et ne s'occupe pas de la partie autorisations.
[^] # Re: la question qui fâche
Posté par Misc (site web personnel) . Évalué à 2.
openid comme provider ( auquel cas, je dirait "+1" ) , ou permettre de s'authentifier à partir d'un provider openid externe ( auquel cas je dirais "bof" ).
# OAuth 1.0 vs. 2.0 ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
Une simple question : pourquoi choisir OAuth 2.0 qui n'est pas actuellement un standard (toujours en cours d'écriture), qui n'est pas stabilisé, qui oblige client et serveur à implémenter et utiliser TLS, qui est très peu utilisé, et enfin qui n'est pas compatible avec OAuth 1.0 ; plutôt que OAuth 1.0 qui est un standard stable et reconnu (RFC), qui ne nécessite pas de gérer le TLS si on le souhaite, et qui est utilisé par un peu tout le monde ?
Ou pourquoi ne pas gérer les deux tout simplement ?
(Perso j'ai pas compris pourquoi OAuth 2.0 a gardé le nom OAuth alors que ça n'est pas rétro-compatible et que ça n'a plus grand chose à voir...)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par __o . Évalué à 10. Dernière modification le 11 décembre 2011 à 23:24.
OAuth2 est beaucoup plus simple.
OAuth utilise une connexion HTTP en clair, et donc doit implémenter des techniques pour vérifier l'authenticité des messages, chiffrage, anti-replay, nonce, etc. Le résultat est que consommer une API OAuth est assez complexe et requière une bibliothèque.
OAuth2 laisse ce travail à TLS, et du coup le protocole est hyper simple. Côté client une bibliothèque HTTP est amplement suffisante pour consommer une API OAuth2.
Forcer l'utilisation de TLS n'est pas un problème pour le client, à mon avis, tant que le serveur a un certificat de confiance.
OAuth2 est utilisé par Facebook entre autres, ce qui fait que la catégorie de développeurs qui a déjà touché à OAuth1 a certainement déjà touché à OAuth2 aussi.
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Voilà, ça résume bien ;-)
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Ça existe ça, un certificat X.509 de confiance ? ^^
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 0.
Bien sûr : il reste CAcert.
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Parce que c'est beaucoup plus simple que OAuth 1.0.
HTML5 est aussi dans cette zone mouvante. Est-ce qu'il faudrait ne pas l'utiliser avant 2022 ?
Si, maintenant, c'est relativement bien stabilisé (même si par le passé, il y a eu de gros changements).
Oui, mais je préfère ça à devoir gérer ça avec des trucs plus bas niveau comme dans OAuth 1.0.
Cough. C'est "juste" utilisé par Facebook, Google, Github, Instagram, Foursquare, 37signals... Bref, en dehors de twitter, ça fait quand même une très grosse partie des API à fort trafic dans le monde.
Certes, mais vu que le numéro majeur de version a changé, ça semble logique.
OAuth est surtout connu pour être très compliqué à implémenter. Et, à part Twitter, je ne crois pas avoir rencontré récemment d'API qui utilise OAuth 1.0.
[^] # Re: OAuth 1.0 vs. 2.0 ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Je suggérerais bien d'oublier cette erreur de la nature et de passer directement à HTML 6 qui (idéalement) séparera HTML de tout le reste du bouzin, cette spéc étant absolument illisible. Mais c'est un autre troll ^^
Normalement c'est la lib utilisée qui fait le boulot note, d'un point de vue dév ça change pas grand chose j'ai l'impression. Par contre oui d'un point de vue développeur de lib OAuth, je suis très heureux de ne plus avoir à mettre le nez dans ce bordel de signatures machin, même si maintenant que c'est fait ça bougera plus.
A part facebook, la plupart (google & co.) qui l'implémentent préviennent que c'est expérimental et que ça peut changer / disparaître à tout moment, ce qui n'est guère rassurant. Mais c'est pas parce que c'est quelques "gros" machins que ça veut dire que c'est répandu... Ça me semble encore relativement rare perso.
Sur le fond je parlais de l'implémentation des libs (provider/consumer/whatever) qui me semble pour le moment relativement faiblarde comparé à ce qui existe pour OAuth 1.0.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Et le spam?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Sur cette page, il est expliqué que l'API permet de récupérer l'adresse mail d'un utilisateur authentifié. Est-ce vraiment souhaitable?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et le spam?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
L'utilisateur doit donner son accord pour qu'une application puisse accéder à ses informations.
[^] # Re: Et le spam?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
C'est dommage que ce soit binaire: je donne accès à toutes mes infos ou à aucune.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Drupal 6
Posté par euroxers (site web personnel) . Évalué à 2.
C'est justement mon cas : ) (http://euromussels.eu/ ) Cette tribune tourne sur Drupal. Comme le module tribune n'est compatible qu'avec la version 6 de Drupal, j'utilise toujours cette version. J'ai l'impression que pour faire fonctionner correctement les modules OAuth2, il faut utiliser Drupal 7 maintenant. Vous me conseillez d'installer quels modules Drupal (en espérant qu'il y a experts de Drupal qui traînent ici)?
# Clair comme de l'eau de roche
Posté par zebra3 . Évalué à 6.
Ouais, c'est pas faux.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Clair comme de l'eau de roche
Posté par CrEv (site web personnel) . Évalué à 7.
c'est dispose que tu n'as pas compris ?
# BrowserID
Posté par bilboa . Évalué à -5.
Utilisr ce que tout le monde utilise c'est bien beau, mais personellement je préfére utiliser ce qui est plus proche de mes valeurs ca qui protége ma vie privée, comme par exemple, BrowserID.
Le concept est interessant d'ailleurs, et puis pas très dur a implémenter.
https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site
[^] # Re: BrowserID
Posté par Buf (Mastodon) . Évalué à 2.
Le concept est peut-être intéressant (ou peut-être pas, j'ai pas regardé en détail), mais ça n'a rien à voir avec ce qui est discuté ici.
[^] # Re: BrowserID
Posté par Larry Cow . Évalué à 3.
Depuis le temps que j'en entends parler sans prendre le temps de m'y intéresser, tu pourrais m'expliquer un truc? Chaque fois que je regarde, j'ai l'impression que c'est tout sauf décentralisé (et complètement dépendant de browserid.org), je me trompe?
[^] # Re: BrowserID
Posté par barmic . Évalué à 3.
BrowserID c'est comme OpenID ça permet juste de fournir une authentification alors qu'avec OAuth on peut gérer des autorisation. De plus BrowserID est lié au navigateur il me semble alors que là l'un des intérêts est de pouvoir créer des clients natif (le renouveau de wmcoincoin ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.