Re: [openplacos-dev] OAuth2.0 |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/openplacos-dev Archives
]
- To: openplacos-dev@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [openplacos-dev] OAuth2.0
- From: flagos <flagospub@xxxxxxxxx>
- Date: Mon, 12 Dec 2011 21:07:45 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=pBDwcY1BP46ZbG6xoQnuwXXgTvdxj9PWWGSRW+qfhuU=; b=ne7aOR+n2b2qBWAqUiPvX3wva55c9bllJ2xce4NFUGPjJgAnKpp1P+uD9+sttUhM/1 ex+3lGTGMWCS6AoMouKT8/kZAGjmvwb/8+9kYywUfgDorBeTqej6tyhTmNW+GJdT9QTE Vr8RctAqZVBhnQXxfG+WwIcdyuTWhxboe01Mg=
lol !
Le 12 décembre 2011 21:04, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> haha, pour acceder a l'api facebook, il faut avoir un compte .... facebook.
> Je vais essayer d'en trouver un pour matter ca.
>
> 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