Re: [openplacos-dev] OAuth2.0

[ Thread Index | Date Index | More lists.tuxfamily.org/openplacos-dev Archives ]


j'ai testé un git clone / bundle install / rails server sur le lien donnée hier.
ca marche plutot bien (avec google), la plupart des autres étant déprécié.
tu t'identifie sur un site tiers, ca te demande si tu est ok pour accéder aux infos XXX et ca créer un compte en local, l'autentification étant géré via le service tiers.


Le 12 décembre 2011 22:35, flagos <flagospub@xxxxxxxxx> a écrit :
J'ajoute dans le thread ce lien, je me sers de la ML comme bookmark ;-)

http://www.communityguides.eu/articles/16


Le 12 décembre 2011 21:15, flagos <flagospub@xxxxxxxxx> a écrit :
> Et bientot sur opos: le compte facebook obligatoire pour vous logguer
> sur le placos !
>
> Le 12 décembre 2011 21:08, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
>> On peut aussi tout faire en xmpp, doit y avoir des fonction sympa .... c'est
>> bon je sort --> [ ]
>>
>>
>> Le 12 décembre 2011 21:03, flagos <flagospub@xxxxxxxxx> a écrit :
>>>
>>> En gros, ce que je voulais dire c'est que REST n'est malheureusement
>>> pas un protocole, mais juste un concept.
>>>
>>> Le 12 décembre 2011 21:03, flagos <flagospub@xxxxxxxxx> a écrit :
>>> > Ouai en fait il manque un protocole pour standardiser la maniere dont
>>> > les interfaces REST communiquent. Ca permettrait d'avoir un truc
>>> > standard pour les metadata et pour savoir en quel format ils sont
>>> > (json, xml, whatever)
>>> >
>>> > OAuth, c'est juste un jeu de fonction précablés pour ces histoires de
>>> > permissions, avec la sécurité en prime.
>>> >
>>> > Le 12 décembre 2011 20:55, flagos <flagospub@xxxxxxxxx> a écrit :
>>> >> Je me promene dans la doc de Facebook. C'est vraiment pas degeu
>>> >>
>>> >> http://developers.facebook.com/docs/reference/api/
>>> >>
>>> >> Alors, je sais pas si c'est une feature de OAuth, ou juste une
>>> >> convention, mais l'introspection vient en ajoutant ?metadata=1 sur
>>> >> l'url. Ce serait bien que ce soit prévu cash dans le protocole.
>>> >>
>>> >> Après, FB ils ont ajouté des petites perles, comme par exemple:
>>> >> http://developers.facebook.com/docs/reference/api/realtime/
>>> >>
>>> >>
>>> >>
>>> >> Le 12 décembre 2011 20:37, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit
>>> >> :
>>> >>> yep
>>> >>>
>>> >>> disons que dbus a ses petits coté assez séduissants (introspect,
>>> >>> efficacité,
>>> >>> d-feet, etc) mais s'oriente plutot sur des applications lourde.
>>> >>> il est effectivement peut etre plus flexible de partir sur du http.
>>> >>>
>>> >>> apres il faut voir ce que ca implique, notamment sur le coté bloquant
>>> >>> des
>>> >>> appel dbus qui evite les colisions.
>>> >>>
>>> >>> Le 12 décembre 2011 19:35, flagos <flagospub@xxxxxxxxx> a écrit :
>>> >>>
>>> >>>> Exactement.
>>> >>>>
>>> >>>> Et ca correspondrait vraiment a OAuth tel qu'on peut le voir déployé
>>> >>>> sur
>>> >>>> FB:
>>> >>>> ca fait: tu te connectes sur un plugin, style rails. Il te demande
>>> >>>> ton
>>> >>>> login, tu es re-routé sur une interface minimale et légère qui
>>> >>>> correspond au core-server:
>>> >>>>
>>> >>>> "Voulez-vous autorisez l'appli rails a accéder a vos infos ? Celle a
>>> >>>> besoin des autorisations suivantes:
>>> >>>> - lecture/ecriture sur objet
>>> >>>> - données capturées dans la db
>>> >>>> - blog
>>> >>>> - whatever"
>>> >>>>
>>> >>>> Et pif tu choisis yes, comme dab.
>>> >>>>
>>> >>>> Une autre idée qui vient avec, c'est que l'appli rails dans cet
>>> >>>> exemple, peut tout a fait être distante pour pleins de bonnes
>>> >>>> raisons.
>>> >>>> http est adapté a ce genre de manipe.
>>> >>>>
>>> >>>> Enfin voila, comme tu dis ca reviendrait a exposer dbus sur http.
>>> >>>> C'est le choix fait par domogik, sauf que pour le coup avec OAuth2,
>>> >>>> on
>>> >>>> aurait un truc plus classe et plus a la page.
>>> >>>>
>>> >>>> Le 12 décembre 2011 19:02, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a
>>> >>>> écrit :
>>> >>>> > Pourquoi pas.
>>> >>>> > Dbus, c'est le tuyau par lequel arrive les infos, il est pas
>>> >>>> > nécessairement
>>> >>>> > moins adapté que http.
>>> >>>> > apres en passant par du http, ben on a acces à tout les truc qui
>>> >>>> > gèrent
>>> >>>> > nativement l'echange de token.
>>> >>>> >
>>> >>>> > Dbus serais gardé pour la mécanique interne du bouzin, et puis au
>>> >>>> > lieu
>>> >>>> > de
>>> >>>> > publier ca sur un autre bus, on publirais directement sur du REST
>>> >>>> > (en
>>> >>>> > mode
>>> >>>> > JSON) via un server embarqué à la con.
>>> >>>> > ca revient remplacer dbus par du JSONRPC..
>>> >>>> >
>>> >>>> > Le 12 décembre 2011 18:11, flagos <flagospub@xxxxxxxxx> a écrit :
>>> >>>> >
>>> >>>> >> Effectivement. On boucle sur les memes raisonnements sur les memes
>>> >>>> >> questions depuis un bon bout de temps.
>>> >>>> >>
>>> >>>> >> A partir de la, il reste 2 soluces:
>>> >>>> >>
>>> >>>> >> l'actuelle: l'API REST de OAuth2 est exposée par un plugin, de
>>> >>>> >> confiance, qui gere authentification + permission d'accès, la
>>> >>>> >> requete
>>> >>>> >> est ensuite routée sur dbus, en clair.
>>> >>>> >> une autre: l'API est exposée directement par le serveur, les
>>> >>>> >> autres
>>> >>>> >> plugins style rails ne servant que de "vue" pour attaquer les
>>> >>>> >> requetes
>>> >>>> >> en REST, transformant le navigateur client en veritable client
>>> >>>> >> opos.
>>> >>>> >>
>>> >>>> >> Cette 2eme soluce nous ferait perdre a terme le cote d-bus pour
>>> >>>> >> les
>>> >>>> >> clients, puisque non entretenu. Cela dit, on a beau retourner le
>>> >>>> >> truc
>>> >>>> >> sous tous les sens (ca fait 15 000 fois qu'on trolle sur le sujet
>>> >>>> >> ;-)
>>> >>>> >> ), c'est la seule solution que j'arrive a trouver logique...
>>> >>>> >>
>>> >>>> >> Le 12 décembre 2011 17:54, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a
>>> >>>> >> écrit
>>> >>>> >> :
>>> >>>> >> > yep
>>> >>>> >> > après c'est toujours pareil, ça dépend du niveau
>>> >>>> >> > de l’authentification.
>>> >>>> >> > c'est clair que si à un moment on veut "authentifier"
>>> >>>> >> > les requêtes envoyé au
>>> >>>> >> > server niveau dbus
>>> >>>> >> > ben je vois pas trop d'autre moyen que le trip des token.
>>> >>>> >> > Toute la subtilité du truc c'est de trouver la bonne lib qui
>>> >>>> >> > nous
>>> >>>> >> > permet
>>> >>>> >> > de
>>> >>>> >> > pas se palucher cette gestion des tokens/sessions etc.
>>> >>>> >> > On a bien regardé dbus, et a part identifier le service ou
>>> >>>> >> > l'user
>>> >>>> >> > unix
>>> >>>> >> > de
>>> >>>> >> > provenance du message, ca va pas plus loin.
>>> >>>> >> > apres doit y avoir moyen de hacker, genre en creer un service
>>> >>>> >> > par
>>> >>>> >> > user
>>> >>>> >> > authentifié, mais bon, plas glopf.
>>> >>>> >> >
>>> >>>> >> > donc ouais faudra regarder ca en detail, mais ca à l'ar
>>> >>>> >> > effectivement
>>> >>>> >> > bien
>>> >>>> >> > adapté
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > Le 12 décembre 2011 17:33, flagos <flagospub@xxxxxxxxx> a écrit
>>> >>>> >> > :
>>> >>>> >> >
>>> >>>> >> >> Oui, pour le champ token, je crois que ca ne resout pas cette
>>> >>>> >> >> affaire
>>> >>>> >> >> la.
>>> >>>> >> >>
>>> >>>> >> >> En fait, je pense que je suis allé un peu vite en conclusion en
>>> >>>> >> >> disant
>>> >>>> >> >> qu'il fallait caler ca dans le serveur. Ca mérite de s'y
>>> >>>> >> >> interesser
>>> >>>> >> >> d'un peu plus pour voir comment ca marche précisément.
>>> >>>> >> >>
>>> >>>> >> >> Ca n'empeche qu'il s'agit pour autant d'une techno vraiment
>>> >>>> >> >> adaptée
>>> >>>> >> >> a
>>> >>>> >> >> notre problématique (vue d'avion). A nous de bien nous
>>> >>>> >> >> architecturer
>>> >>>> >> >> autour de cette question une fois qu'on aura bien capté comment
>>> >>>> >> >> marche
>>> >>>> >> >> le bousin.
>>> >>>> >> >>
>>> >>>> >> >> Le 12 décembre 2011 17:23, miaouf kirsh <miaoufkirsh@xxxxxxxxx>
>>> >>>> >> >> a
>>> >>>> >> >> écrit
>>> >>>> >> >> :
>>> >>>> >> >> > Oui effectivement, c'est quelque chose d'assez intéressant.
>>> >>>> >> >> > bon j'ai pas tout saisi en clair, mais j'ai toujours été
>>> >>>> >> >> > assez
>>> >>>> >> >> > favorable
>>> >>>> >> >> > à
>>> >>>> >> >> > l'intégration de l'authentification au niveau du server.
>>> >>>> >> >> >
>>> >>>> >> >> > Sinon est-ce que ca implique des choses niveau dbus client
>>> >>>> >> >> > (genre
>>> >>>> >> >> > rajouter
>>> >>>> >> >> > un champ token pour chaque appel de methode ?)
>>> >>>> >> >> >
>>> >>>> >> >> > Le 12 décembre 2011 08:54, flagos <flagospub@xxxxxxxxx> a
>>> >>>> >> >> > écrit :
>>> >>>> >> >> >
>>> >>>> >> >> >> Yop,
>>> >>>> >> >> >>
>>> >>>> >> >> >> Vous l'avez peut eter vu passer dans vos radars RSS, DLFP
>>> >>>> >> >> >> propose
>>> >>>> >> >> >> une
>>> >>>> >> >> >> authentification OAuth2 pour que des applis externes
>>> >>>> >> >> >> puissent se
>>> >>>> >> >> >> connecter sur le site. Bon c'est un détail mais ca m'a amené
>>> >>>> >> >> >> a me
>>> >>>> >> >> >> pencher sur OAuth2..
>>> >>>> >> >> >>
>>> >>>> >> >> >> Il s'agit d'un protocole d'un protocole d'identification et
>>> >>>> >> >> >> de
>>> >>>> >> >> >> gestion
>>> >>>> >> >> >> de droits d'accès par session et par user (si j'ai bien
>>> >>>> >> >> >> compris
>>> >>>> >> >> >> !)
>>> >>>> >> >> >> Les transmissions de mdp sont au moins hashes, les
>>> >>>> >> >> >> transmissions
>>> >>>> >> >> >> sont
>>> >>>> >> >> >> prévues par le protocole en TLS.
>>> >>>> >> >> >>
>>> >>>> >> >> >> L'authentification resterait a notre sauce, ce qui serait
>>> >>>> >> >> >> egalement
>>> >>>> >> >> >> un
>>> >>>> >> >> >> bon point puisqu'on voulait pouvoir deporter
>>> >>>> >> >> >> l'authentification
>>> >>>> >> >> >> sur
>>> >>>> >> >> >> du
>>> >>>> >> >> >> LDAP, du unix-based ou une liste dans la db SQL.
>>> >>>> >> >> >>
>>> >>>> >> >> >> En plus, on pourrait cash le caler dans le core-serveur, ce
>>> >>>> >> >> >> serait
>>> >>>> >> >> >> vraiment le cadre idéal ! Ca m'a l'air vraiment super adapté
>>> >>>> >> >> >> comme
>>> >>>> >> >> >> petit protocole...
>>> >>>> >> >> >>
>>> >>>> >> >> >> # Quelques liens
>>> >>>> >> >> >> http://hueniverse.com/2010/05/introducing-oauth-2-0/
>>> >>>> >> >> >> http://en.wikipedia.org/wiki/OAuth
>>> >>>> >> >> >>
>>> >>>> >> >> >> # Un petit gem qui apparait fait bien son travail
>>> >>>> >> >> >> https://github.com/intridea/omniauth
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >> --
>>> >>>> >> >> >> Tapé depuis mon clavier
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >> --
>>> >>>> >> >> Tapé depuis mon clavier
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> --
>>> >>>> >> Tapé depuis mon clavier
>>> >>>> >>
>>> >>>> >>
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Tapé depuis mon clavier
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Tapé depuis mon clavier
>>> >
>>> >
>>> >
>>> > --
>>> > Tapé depuis mon clavier
>>>
>>>
>>>
>>> --
>>> Tapé depuis mon clavier
>>>
>>>
>>
>
>
>
> --
> Tapé depuis mon clavier



--
Tapé depuis mon clavier





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/