クライアントが、そのクライアント用に設定したランディング ページで外部 API への呼び出しを実装することを望んでいるシナリオを想像してください。外部 API は、契約とその契約を通じて取得される API キーに基づいて動作します。したがって、fetch()フロントエンドからの呼び出しで API キーを公開してはなりません。
したがって、中間サーバーとして機能し、LP の呼び出しを外部 API に接続する Docker インスタンスを実装する義務が生じfetch()、すべてのリクエストで次のトラフィックが発生します。
client --> Docker container --> API --> Docker container --> client
セキュリティを厳重に保つために、クライアントから Docker コンテナに着信するリクエストを認証する最適なアプローチについて考えてみましょう。認証は、ページの読み込み時、つまり初期認証が成功した後にクライアントに配信される CSRF トークンを介して実装されます。
ランディングページにはログイン システムがなく、非 HTTP / サードパーティの Cookie に依存できないことを考えると、デプロイされたランディングページのドメインから発信されたリクエストのみが Docker コンテナーに入るようにすることを考えました。しかし、A) これが可能かどうか ( Acces-Control-Allow-OriginDocker コンテナーの設定について考えましたか?)、B) これが安全かどうかはわかりません。特に B) については疑問に思っています。リファラー ヘッダーのようなものを偽造するのは非常に簡単なので、リクエストの発信元のドメイン名も簡単に偽造できるのではないかと思うからです。
私が正しく理解していれば、ヘッダー経由で提供されるルールはAccess-Control-Allow-Originブラウザーでのみ適用され、たとえば単純な HTTP クライアントはそれを回避/無視できるということですが、正しいでしょうか?
基本認証も考えましたが、その場合は js に認証トークンを提供する必要があるため、クライアント コード内で何も公開しないような認証の方が望ましいと思います。
DockerコンテナがApache上で動作することを考えると、このユースケースに対する最も厳格な解決策は、デプロイされたLPのIPへのアクセスを制限することだと思います。これ、次のようなものを使用してこれこれはアクセス制限と認証の違いであることは承知していますが、クライアントに何も公開しないこのランディング ページのシナリオではこれが最善のソリューションであると思います。