| [openplacos-dev] Re: foutus token |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/openplacos-dev Archives
]
- To: openplacos-dev@xxxxxxxxxxxxxxxxxxx
- Subject: [openplacos-dev] Re: foutus token
- From: flagos <flagospub@xxxxxxxxx>
- Date: Tue, 31 Jan 2012 08:24:14 +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=q6wSuwkej4PGhVSH7/eoOf1NooKs4LxH33kpWpl/S10=; b=ocZgYKH1KFCFNhKJSRg9ZVk9bo3awspppYGAyy3hQWb+mjlAaCnzZFyaqWK232GVaS fqek5rXqfF4Q0EwvgF0rPGj3hqupbd5kzuwpF3ewHSZQHbEdwAat+Yp8e9aaCRGXiLNS Ew4Gjw8iLP2wXQ6YBMBsNzyYdJ9M7mL4XUawk=
Je fais un up sur le sujet, faut qu'on avance la dessus aussi
Je reprends le truc depuis le debut:
soit on dit que chaque serveur genere ses propres cles => ce qui
oblige a faire un protocole pour que les applis demande
automatiquement une clé. C'est faisable via une api rest par exemple.
Il faut ensuite qu'elle stocke cette clé et qu'elle offre un moyen
facile pour l'utilisateur de supprimer cette clé (en cas de format de
la machine par exemple). Ca me semble pas infaisable, mais cela
remonte de la complexité au niveau appli. La sécurité n'est pas
compromise. Cependant on dévie clairement de oauth2, y va y avoir du
hack autour des libs pour oauth2.
soit on centralise la gestion des clés => ca nous oblige a gerer un
truc en central pour que les gens qui veulent faire leur applis
puissent s'incrire (un mail ca suffit) et a faire un wget pour aller
recuperer la derniere version (ou via des machins de migration a
chaque release d'opos ?). On revient a un fonctionnement classique de
oauth2. Il faut bien faire gaffe a ce qu'on recupere pour pas
compromettre la sécurité du bouzin. Un avantage aussi est qu'un
instance d'un client pour fonctionner sur 2 opos differents sans avoir
15 000 considerations a gerer.
Le 28 janvier 2012 12:28, flagos <flagospub@xxxxxxxxx> a écrit :
> Yop,
>
> Bon j'aimerai faire le point sur ces histoires de tokens pour oauth2.
> Distinguons plusieurs cas:
>
> Les pseudo clients: il s'agit des plugins locaux qui font passerelle,
> ex: rails, jabber. Ils ont l'avantage d'etre en local, on peut
> facilement recuperer leurs token en local, suffit de se mettre
> d'accord sur un petit formalisme.
>
> Les clients distants: Il s'agit d'une appli distribué sur le device du
> client. ex: widget gnome, CLI, appli android. Je ne sais pas quelle
> confiance on peut accorder a un client-secret distribué de cette
> maniere.
>
> Les autres sites web: ex: rails s'il est intallé sur un serveur
> central pour mutualiser les ressources. On est en pleins dans oauth2.
> Le client-secret ne peut pas etre regeneré a chaque fois. => besoin
> d'une db distante et centrale pour ceux la, a moins que le site
> manipule autant de client-secret que de serveurs vers lequel il peut
> se connecter.
>
> --
> Tapé depuis mon clavier
--
Tapé depuis mon clavier