キー/シークレットの組み合わせを介してアクセスを許可する歴史的な API を使用しています。元の API 設計者が指定したものは、HTTP 基本認証ヘッダーでユーザー名とパスワードとして渡す必要があります。
curl -u api_key:api_secret http://api.example.com/....
私たちの API クライアントベースが拡大しつつある今、3scaleを使用して認証、レート制限、およびその他の機能の両方を処理することを検討しています。3scale の指示とアドバイスに従って、API サーバーの前で Nginx プロキシを使用します。これは、3scale のサービスに対して認証を行い、すべてのアクセス制御システムを処理します。
既存のクライアントのキーとシークレットを 3scale にエクスポートし、2 つのシステムの同期を維持します。返されるデータの一部はクライアント固有であるため、既存のアプリが引き続き既存の方法でキーとシークレットを受信する必要があります。ただし、3scale が認証方法としてネイティブにサポートしていない HTTP 基本認証リクエストを、書き換えられたカスタム ヘッダーに変換する方法を見つける必要があります。
3scale が構成する Nginx および Lua 構成を使用して、プロキシをセットアップできました。これにより、-u key:secret
がサーバーに渡され、正しく処理されます。ただし、現時点では、3scale がアクセスを管理できるように、同じ認証情報をクエリ パラメーターまたはカスタム ヘッダーとして追加する必要があります。Nginx プロキシにそれを処理してもらいたいので、ユーザーは既存の方法で 1 セットの認証詳細を提供し、3scale もそれを取得できます。
Ruby などの私が知っている言語では、HTTP_AUTHORIZATION ヘッダーをデコードし、Base64 でエンコードされた部分を取り出してデコードし、提供されたキーとシークレットのコンポーネントを見つけることができます。しかし、私はNginxの初心者であり、Nginx内で同じことを達成する方法がわかりません(また、3scaleが提供するLuaスクリプトがソリューションの一部になる可能性があるかどうかもわかりません)...