Re: [openplacos-dev] OAuth2.0

[flagos <flagospub@xxxxxxxxx>]

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