> 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