Authentification HTTP de base et authentification des clés porteuses
je suis en train de développer une API REST qui est HTTP-Basic protégée pour l'environnement de développement. Comme l'authentification réelle se fait via un jeton, j'essaye toujours de comprendre, comment envoyer deux en-têtes d'autorisation.
j'ai essayé celui-ci:
curl -i http://dev.myapp.com/api/users
-H "Authorization: Basic Ym9zY236Ym9zY28="
-H "Authorization: Bearer mytoken123"
je pourrais par exemple désactiver l'authentification HTTP pour mon IP mais comme je travaille habituellement dans différents environnements avec des IPs dynamiques, ce n'est pas une bonne solution. Alors suis-je raté quelque chose?
5 réponses
essayez celui-ci pour pousser l'authentification de base à l'url:
curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
^^^^^^^^^^^^^^^^^^
Si l'un ne fonctionne pas, alors vous n'avez rien à faire avec elle. Essayez donc les alternatives suivantes.
, Vous pouvez passer le jeton sous un autre nom. Parce que vous vous occupez de l'autorisation de votre demande. Vous pouvez donc facilement utiliser cette flexibilité pour ce but spécial.
curl -i http://dev.myapp.com/api/users \
-H "Authorization: Basic Ym9zY236Ym9zY28=" \
-H "Application-Authorization: mytoken123"
notez que j'ai changé l'en-tête en Application-Authorization . Donc, à partir de votre application, saisissez le jeton sous cet en-tête et traitez ce que vous devez faire.
une autre chose que vous pouvez faire est de passer le token par les paramètres POST et de saisir la valeur du paramètre du côté du serveur. Par exemple, passer un jeton avec le paramètre curl post:
-d "auth-token=mytoken123"
Standard ( https://tools.ietf.org/html/rfc6750 ) dit que vous pouvez utiliser:
- Forme Codée Corps Paramètre: Autorisation: Porteur mytoken123
- paramètre de requête URI: access_token=mytoken123
il est donc possible de passer beaucoup de jeton porteur avec URI, mais faire cela est déconseillé (voir la section 5 dans le standard).
curl --anyauth
dit à curl de comprendre la méthode d'authentification par elle-même, et d'utiliser le le plus sécurisé que le site distant prétend supporter. Ceci est fait par d'abord faire une demande et vérifier les en - têtes de réponse, ainsi provoquer un réseau supplémentaire de l'aller-retour. Ce est utilisé au lieu de définir une méthode d'authentification, que vous pouvez faire avec de base--, --digérer, --ntlm, et --négocier.
Si vous utilisez un proxy inverse comme nginx entre les deux, vous pouvez définir un token personnalisé, tels que X-API-Token .
dans nginx vous le réécriviez pour que le proxy amont (votre api rest) soit juste auth:
proxy_set_header Authorization $http_x_api_token;
... tandis que nginx peut utiliser l'en-tête D'autorisation d'origine pour vérifier HTTP AUth.
j'ai eu un problème similaire - authentifier l'appareil et l'utilisateur à l'appareil. J'ai utilisé un en-tête Cookie à côté d'un en-tête Authorization: Bearer... .