私は現在、開発環境用にHTTP-Basicで保護されたREST-APIを開発しています。実際の認証はトークンを介して行われるので、2つの認証ヘッダーを送信する方法を見つけようとしています。
私はこれを試しました:
curl -i http://dev.myapp.com/api/users \
-H "Authorization: Basic Ym9zY236Ym9zY28=" \
-H "Authorization: Bearer mytoken123"
たとえば、自分のIPのHTTP認証を無効にすることもできますが、通常は動的IPを使用するさまざまな環境で作業しているため、これは良い解決策ではありません。だから私は何かが足りない?
これを試してみてください。URLで基本認証をプッシュします。
curl -i http://username:[email protected]/api/users -H "Authorization: Bearer mytoken123"
^^^^^^^^^^^^^^^^^^
上記のいずれかがうまくいかない場合は、あなたはそれとは関係ありません。それで、以下の代替案を試してください。
トークンを別の名前で渡すことができます。あなたはあなたのアプリケーションからの承認を処理しているからです。ですから、この特別な目的のためにこの柔軟性を簡単に使うことができます。
curl -i http://dev.myapp.com/api/users \
-H "Authorization: Basic Ym9zY236Ym9zY28=" \
-H "Application-Authorization: mytoken123"
ヘッダをApplication-Authorization
に変更しました。だからあなたのアプリケーションからそのヘッダの下のトークンをキャッチし、あなたがする必要があることを処理する。
token
をPOST
パラメータに渡し、サーバ側からパラメータの値を取得することもできます。例えば、curl postパラメータを使ってトークンを渡す:
-d "auth-token=mytoken123"
標準( https://tools.ietf.org/html/rfc6750 )には、次のものを使用できます。
そのため、URIで多くのBearer Tokenを渡すことは可能ですが、これを行うことはお勧めできません(標準のセクション5を参照)。
その間にnginxなどのリバースプロキシを使用している場合は、X-API-Token
などのカスタムトークンを定義できます。
Nginxでは、上流プロキシ(残りのapi)がauthになるように書き換えるでしょう。
proxy_set_header Authorization $http_x_api_token;
... nginxはHTTP AUthをチェックするためにオリジナルのAuthorizationヘッダを使うことができます。
カール - anyauth
それ自身で認証方法を見つけ出し、リモートサイトがサポートすると主張する最も安全な方法を使用するようにcurlに指示します。これは最初にリクエストを行い、レスポンスヘッダをチェックすることによって行われます。したがって、余分なネットワークラウンドトリップを引き起こす可能性があります。これは、--basic、 - digest、--ntlm、および--negotiateで実行できる特定の認証方法を設定する代わりに使用されます。
私は同様の問題を抱えていた - デバイスでデバイスとユーザーを認証します。私はAuthorization: Bearer...
ヘッダーと一緒にCookie
ヘッダーを使用しました。