Impossible de tester l'API avec authentification sur la preprod
GerardPaligot opened this issue · 28 comments
Depuis toujours (même à l'époque des tests sur l'API des membres), il était impossible de tester l'API si nous avions besoin d'une requête authentifiée pour une "simple" raison :
L'en-tête de la protection htaccess et l'en-tête d'authentification de l'API sont identiques et s'écrasent l'un l'autre.
Alors pour les membres, c'était pas "trop" dérangeant. La plupart des URLs étaient non authentifiées. Par contre, ça l'est beaucoup plus pour les MPs puisqu'elles sont toutes authentifiées. Nous risquons donc de mettre en prod quelque chose qui n'a pas été testé dans un environnement semblable à la prod et avoir des problèmes graves en prod (imaginez que vous pouvez récupérer les MPs de tout le monde !).
Je tag donc bloquant et infra puisque c'est un souci d'infrastructure de la preprod.
solution simple : virer les authentifiant htaccess de la preprod. Est-ce un problème ? Il y a t'il un risque a faire cela ?
Si on vire le contrôle d'accès de la préprod, on doit garantir que le contenu de cette préprod reste invisible aux robots d'indexation.
La seule piste que j'ai, c'est celle-ci : http://www.django-rest-framework.org/api-guide/authentication/#apache-mod_wsgi-specific-configuration
Mais, à ma connaissance, nos serveurs ne sont pas derrière un Apache. Il faudrait voir s'il existe un équivalent sous nginx.
D'après Google, un bête robots.txt ne suffirait pas à lui interdire l'accès : il suffirait d'un lien vers le site pour qu'il indexe quand même.
Les autres solutions proposées sont le contrôle d'accès actuel ou une solution lourde à base de balise meta.
Cette issue est-elle bloquante par rapport à la release 15.5.1 ? (Sachant que l'API sera désactivée en prod)
On peut pas faire en sorte que l'authentification http utilise les même login/mdp que nos comptes ? C'est pour moi le plus simple :
- les robots ne pourraient pas y accéder
- on a plus de probs de collisions puisque les deux en tete représenteraient la même chose et attendraient la même valeur
Le seul défaut que je vois est que ça limite l'accès à la beta aux membres qui ont un compte mais ça me semble être un moindre mal.
Je ne suis déjà pas certain que c'est possible puis je suis encore moins certain que ça fonctionne. L'API a besoin d'envoyer un token d'authentification dans l'en-tête qui a été généré par oauth2_provider. Je ne suis pas certain que ça soit compatible avec l'authentification htaccess du serveur de preprod.
Le token est pas envoyé avec le meme champs donc ça importe peu. Quand
j'avais essayé, d'après mes souvenirs, c'était le champs de login qui était
identique aux deux méthode où il fallait mettre ton login pour oauth et
clémentine pour le passage http.
Christophe
Le 22 mai 2015 10:18, "Gérard Paligot" notifications@github.com a écrit :
Je ne suis déjà pas certain que c'est possible puis je suis encore moins
certain que ça fonctionne. L'API a besoin d'envoyer un token
d'authentification dans l'en-tête qui a été généré par oauth2_provider.
Je ne suis pas certain que ça soit compatible avec l'authentification
htaccess du serveur de preprod.—
Reply to this email directly or view it on GitHub
#2708 (comment)
.
Sinon, c'est possible de renommer le header Authorization oauth vers quelque chose comme "X-API-Authorization" ?
C'est à dire que les requètes vers l'API comporteraient dans les header un champ "X-API-Authorization", qui contiendrait la clé d'API. L'on peut à priori (pas testé par contre) ensuite configurer nginx pour qu'il transforme le header "X-API-Authorization" en "Authorization", pour que ce soit celui-ci qui soit pris en compte par Django. La directive nginx ressemblerait à quelque chose comme ça:
proxy_set_header Authorization $http_x_api_authorization
Un test de l'API en préprod ressemblerait donc à
curl -H "Authorization: Basic Y2xlbWVudGluZTpvcmFuZ2U=" -H "X-API-Authorization: Bearer wERPXXHpYAsJV29eATLjSO2u5bamyw" https://zestedesavoir.com/api/membres/1/Si on doit changer un en-tête, c'est pas celui de l'API qui doit rester le plus standard possible (pour des raisons évidentes d'utilisation par les applications tiers).
Hum... La préprod est la pour l'API pour tester les nouvelles API, donc lors du développement d'application... De toutes façons, il faut modifier l'url à laquelle l'application tierce fait ses requêtes, donc changer le nom d'un header en plus, c'est pas non plus insurmontable...
Entre une API pas testable, et une API où il faut modifier une ligne dans son code pour tester en préprod...
Le header d'authentification HTTP "basique" ne peut pas être modifié, puisque l'envoi de ce dernier est géré par le navigateur, de manière standardisée
Et via nginx on peut pas triché pour que la route de l'API court-circuite l'authentification ?
On ne peut pas simplement mettre les identifiants dans l'URL comme par exemple https://clementine:orange@beta.zestedesavoir.com/api/ ?
On ne peut pas simplement mettre les identifiants dans l'URL comme par exemple https://clementine:orange@beta.zestedesavoir.com/api/ ?
Non, parce qu'au final, en faisant cela, le navigateur va remplir le header "Autorization" tout seul
Ah ok, j'ai compris
@GerardPaligot comme convenu lors du dernier ZM tu pourras nous faire une PR de désactivation de l'API des MP pour virer le tag bloquant ici et ne pas bloquer la release à venir, le temps de trouver une solution viable.
API des MP commenté pour le moment, j'enlève le bloquant mais garde le ticket ouvert.
Voila qui est réglé, la route de l'api est maintenant sorti de l'autentification serveur (auth_basic) mais soumise cependant à un filtre ip pour éviter que l'on fasse fuiter des infos si jamais l'API était bugguée.
@Eskimon Ca veut dire que seulement quelques personnes peuvent tester l'API ?
Dans l'immédiat oui. Si cependant tu peux expliquer que "l'API peux pas fuiter si le site fuite pas" (car l'API wrap sur le site) alors je pourrais ouvrir à tous alors.
Chui pas clair ?
J'ai rien pigé non. ^^
Je reformule.
Si l'API utilise les mêmes méthodes que les views, alors l'API expose exactement les mêmes risques que les views classique et que le site lui même. En revanche, si l'API travaille selon un biais différent, alors le filtrage IP est pertinent au cas où .
Oui et non :
- Oui, il y a du code commun.
- Oui, il s'agit d'un autre point d'entré pour les mêmes fonctionnalités.
- Non, l'API dispose de son propre framework technique pour accéder aux données.
Donc, je suppose que le filtrage IP est pertinent mais est-ce la solution définitive ? N'est-il pas possible de filtrer autrement ?
Je trouve que le débat n'as pas de sens : le but du .htaccess, c'est pas d'empêcher n'importe qui de faire n'importe quoi, c'est d'empêcher de se faire indexer (en tout cas, c'est toujours comme ça qu'on me l'as présenté). Non ? :)
@pierre-24 Toutafé mais si on a un bug dans l'API qui expose absolument toutes les données de tout le monde, ça serait pas cool.
En fait n'a envie de dire : Si on a des TU qui prouve que les données privées restent privées alors le filtrage n'a pas lieu d'être.
Mais sinon, non, a ma connaissance on a pas d'autre moyen de filtrage que le htpasswd ou IP.