Comments on: The User is dead http://sametmax.com/the-user-is-dead/ Du code, du cul Sat, 07 Nov 2015 11:08:18 +0000 hourly 1 http://wordpress.org/?v=4.1 By: Louis http://sametmax.com/the-user-is-dead/#comment-164653 Tue, 29 Sep 2015 11:50:18 +0000 http://sametmax.com/?p=16615#comment-164653 https://auth0.com/blog/2015/09/28/5-steps-to-add-modern-authentication-to-legacy-apps-using-jwts/

]]>
By: Sam http://sametmax.com/the-user-is-dead/#comment-164534 Sun, 20 Sep 2015 20:24:43 +0000 http://sametmax.com/?p=16615#comment-164534 Pour l’archi c’est un problème plus compliqué, et ça dépend beaucoup de l’objectif.

Est-ce que tu veux coupler l’auth et le reste de l’app, sont-ce des services séparés et indépendants ? L’auth fait-il la supposition d’une forme de stockage ou est-ce que c’est aussi un service séparé ?

Ensuite, est-ce que tu dev juste pour toi, où tu fais un framework ?

L’archi la plus flexibles serait d’avoir 3 services, un pour l’auth, un pour le stockage, et le reste. Mais ça a un coup niveau perf et en termes de couches d’abstraction à maintenir.

En partant sur du un une session => un compte => une identité, et en supposant qu’il n’y a pas de hiérarchie d’identités, on aura donc au moins une identité centrale qui solidarise tout, et un compte avec un type, et des meta information, et un profile de compte qui lui dépend du type de compte (local, facebook, etc).

On a des identifiants qui font passer par un backend qui va devoir retourner une identité et l’attacher à la session, sachant que la session doit être l’objet central à ce moment. Stocker ou pas la session dépend du besoin d’historique, perso je ne le fais pas.

Si on se sent chaud, on peut rajouter une notion de point de connexion, qui est un intermédiaire entre le l’identité et le compte qui comprend des choses comme des identifiants unique (clé API, etc) ou le moyen de connexion (client, device, url de connexion…), etc. Ca peut être utile si on a une app web qui utilise ce genre d’API. C’est également le point d’entrée des web hook, c’est à dire le point d’entrée des services externes autorisés par le détenteur de l’identité. Dans ce cas, la connexion ordinaire devient une de ces opérations également, et ça rajoute une couche. C’est chiant, mais c’est plus flexible.

Les permissions, pareillement, sont liées à un compte, ou au point de connexion et non à une identité, puisque que ce sont les permissions des actions qu’on peut faire sur ce compte/point de connexion. Le compte local devient donc un service comme les autres.

La session permet juste un accès rapide au compte “local” pour obtenir les permissions et le profile “locaux” avec un cache pour un accès rapide.

La partie la plus compliquée, c’est l’auth, car tout ne se passe pas par une logique identifiants = connection. Et faire un truc générique, c’est très chaud, et ça dépend du nombre de services visés, de leur nature, du degré d’intégration et des phases de la lune.

]]>
By: c24b http://sametmax.com/the-user-is-dead/#comment-164532 Sun, 20 Sep 2015 16:18:54 +0000 http://sametmax.com/?p=16615#comment-164532 Je posais précisement la question est termes d’archi avec un cas concret mais merci oui en regardant sur django all auth on commence a avoir une idée de comment coutourner le truc: http://django-allauth.readthedocs.org/en/latest/advanced.html#custom-user-models

]]>
By: Sam http://sametmax.com/the-user-is-dead/#comment-164375 Sat, 12 Sep 2015 14:27:29 +0000 http://sametmax.com/?p=16615#comment-164375 Ceci n’a rien à voir avec l’article. L’article détaille un problème d’architecture, et utilise l’approche de Django comme exemple. Ce n’est PAS un article sur l’authentification multiple incluant des services tierces parties en général, qui n’est qu’un sous ensemble de cette problématique. Problématique par ailleurs résolue par des libs comme django-allauth (http://django-allauth.readthedocs.org/en/latest/) cité dans les commentaires un peu plus haut.

]]>
By: c24b http://sametmax.com/the-user-is-dead/#comment-164374 Sat, 12 Sep 2015 12:17:38 +0000 http://sametmax.com/?p=16615#comment-164374 L’objectif c’est un utilisateur authentifié avec un ou plusieurs mode d’authentification:

soit UserA ==> twitter+ fb + compte onsite avec droit spécifiques et infos supp

par exemple qui correspond à la même personne

et pas à 2 comptes différents

Je suppose qu’il faut surclasser le model User avec une classe Identity par exemple

faire des vérifs en base avec un param unique et ajouter s’il existe et register form sinon?

]]>
By: Sam http://sametmax.com/the-user-is-dead/#comment-164356 Fri, 11 Sep 2015 14:47:28 +0000 http://sametmax.com/?p=16615#comment-164356 ça veut dire quoi “contourner le truc” ? Quel est ton objectif ? Quel résultat concret te permettra de dire qu’il est atteint ?

]]>
By: c24b http://sametmax.com/the-user-is-dead/#comment-164355 Fri, 11 Sep 2015 14:05:10 +0000 http://sametmax.com/?p=16615#comment-164355 noob question: tout à fait d’accord mais dans ce cas uhn indice à donner ou un use case pour contourner le truc?

]]>
By: Sam http://sametmax.com/the-user-is-dead/#comment-163736 Wed, 05 Aug 2015 15:21:37 +0000 http://sametmax.com/?p=16615#comment-163736 Parce que toutes les apps pluggables partent du principe qu’il y a un objet User très rigide ce qui amène plein de problématiques à contourner dès qu’on sort de ce use case.

]]>
By: hugras http://sametmax.com/the-user-is-dead/#comment-163735 Wed, 05 Aug 2015 14:05:42 +0000 http://sametmax.com/?p=16615#comment-163735 article pertinent mais pourquoi critiquer django sur ce point ?

j’ai substitué l’auth de django à celle du serveur ldap de mon entreprise sans trop d’effort via un module dédié.

le framework propose juste un service d’auth par défaut mais qui peut dégager si besoin.

]]>
By: Sam http://sametmax.com/the-user-is-dead/#comment-163446 Tue, 21 Jul 2015 16:57:03 +0000 http://sametmax.com/?p=16615#comment-163446 https://encrypted.google.com/search?hl=fr&q=sametmax%20crossbar

]]>