Development #2861
système d'authentification
0%
Description
Il faut penser à ajouter un système d'authentification au moins basique pour l'accès à certains webservices (exemple: intégration de données dans Solis).
Premières réponses faisables dans l'état actuel :- filtrer certaines URLs au niveau apache
- ajouter un paramètre "&apikey=..." (ou équivalent) dans le modèle de données à restreindre
Fichiers
Historique
Mis à jour par Thomas Noël il y a presque 11 ans
- Fichier passerelle-apiuser-start.patch ajouté
- Statut changé de Nouveau à En cours
- un modèle
ApiUsertel que décrit dans Base - un modèle
BaseResourcesur lequel se basent toutes les ressources proposées par Passerelle (i.e. datasource et repost pour l'instant)
- ajouter un middleware capable de détecter un apiuser (si signature, la vérifier et chercher l'apiuser ; si apikey, chercher l'apiuser)
- ajouter un contrôle de l'apiuser dans BaseResource.check_user() par exemple... voir comment proposer ça facilement dans les vues, idéalement de façon transparente, j'ai pas encore regardé comme faire joliment
- la migration vers cette nouvelle architecture ajoute seulement des tables pour les manytomany, mais ça rend le syncdb inopérent : il va falloir passer par South pour migrer vers cette nouvelle version
- le modèle commun BaseResource devrait permettre de rendre le slug unique, et donc d'avoir juste des URL /slug (sans le prefix /data ou /repost ou autre) : le url.py chercherait la ressource et appelle ensuite le resolveur d'URL du type de ressource cible ? Mouaich... peut-être une fausse bonne idée
- peut-être ajouter un flag "public" pour permettre à une ressource d'être listée dans le frontoffice public même si elle est protégée (i.e. qu'elle possède au moins un "apiuser") -- sachant que par défaut, il faudra que seul un admin pourra voir toutes les ressources sur les pages frontoffice.
Mis à jour par Thomas Noël il y a presque 11 ans
- Fichier passerelle-apiuser-start.patch ajouté
Oups... le patch complet...
Mis à jour par Frédéric Péters il y a presque 11 ans
Je lisais il y a quelques jours http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#authentication
By always using SSL, the authentication credentials can be simplified to a randomly generated access token that is delivered in the user name field of HTTP Basic Auth. The great thing about this is that it's completely browser explorable. […]
Et je trouve que ce serait en effet pas mal de gérer la situation username/key comme username/password, sur une authent HTTP. Non ?
Mis à jour par Thomas Noël il y a presque 11 ans
- si request.META['HTTP_AUTHORIZATION'] => unbase64 => user = chercher(origin, key)
- si signature dans query-string => user = chercher(origin) et vérifier le hmac avec sa clé
- si apikey => user = chercher(apikey)
Mis à jour par Thomas Noël il y a presque 11 ans
- Fichier passerelle-apiuser-models-and-middleware.patch passerelle-apiuser-models-and-middleware.patch ajouté
Un patch plus complet, avec le middleware. Dans les vues on disposera alors d'un request.apiuser, qui sera un ApiUser ou None.
Le middleware détecte :- les URLs signées avec
...&orig=username&algo=...×tamp=...&nonce=...&signature=...si la clé de "username" est bien celle qui a produit la signature selon l'algo de http://doc.entrouvert.org/portail-citoyen/ - ou une
&apikey=...dans la requête - ou une authentification avec username et mot de passe correspondant à une clé de signature
Mis à jour par Thomas Noël il y a presque 11 ans
- Fichier passerelle-apiuser-south.patch passerelle-apiuser-south.patch ajouté
L'ajout de "south" qui sera nécessaire pour faire ce qui précède.
Mis à jour par Thomas Noël il y a presque 11 ans
- Statut changé de En cours à Résolu (à déployer)
Voilà, c'est poussé
Mis à jour par Thomas Noël il y a plus de 10 ans
- Fichier 0001-access-control-through-apiuser.patch 0001-access-control-through-apiuser.patch ajouté
- Echéance mis à 07 octobre 2013
- Statut changé de Résolu (à déployer) à En cours
- Assigné à mis à Thomas Noël
La suite, un peu passée aux oubliettes... la vérification des accès dans les vues.
J'en ai profité pour factoriser, rendre les vues un peu plus génériques, etc.
Mis à jour par Benjamin Dauvergne il y a plus de 10 ans
Les méthodes comme get_from_slug() vont normalement sur l'objet Manager, mais je ne suis pas orthodoxe sur ce point.
J'aurai plutôt vu /templates/passerelle/base/ comme racine des nouveaux templates plutôt que /templates/base/ mais c'est personnel.
J'aurai bien vu une méthode get_for_user(user) sur le manager de l'objet BaseResource plutôt que de voir ce code uniquement dans ResourceIndexView.get_queryset.
Bon sinon les patchs qui contiennent plus de rouge que de vert, c'est trop bien.
Mis à jour par Thomas Noël il y a plus de 10 ans
Nouvelle version, qui intègre les remarques de Benji + l'adaptation de "queue" apparu entre temps.
Mis à jour par Frédéric Péters il y a presque 10 ans
- Statut changé de En cours à Fermé
- Patch proposed mis à Non
Ça a été poussé depuis.