1

しばらくの間、私のチームと私は、クライアントを使用して API サーバーに取り組んできました。別のサーバーを認証サーバーとして使用したいと考えています。下の図を考えてみましょう。

+----------+
|          |
|  Client  |
|          |
+-^------+-+
  |      |
 (6)    (1)
  |      |
  |      |
+-+------v-+            +----------+
|          +----(2)----->          |
|  Proxy   |            |   Auth   |
|          <----(3)-----+          |
+-^------+-+            +----------+
  |      |
 (5)    (4)
  |      |
  |      |
+-+------v-+
|          |
|  Apache  |
|          |
+----------+

現在、このリバース プロキシとして Varnish Cache をセットアップしています。これは、1 つの非常に重要な問題まで問題なく動作します。上記のフローを実現するには、クライアントによってヘッダーで提供されたアクセストークンの有効性について認証サーバーがポーリングされた後、ワニスループを再起動する必要があります。ここでの奇妙な点は、POST リクエスト (認証も必要) を送信するときに、再起動ループの後に varnish が POST リクエストの本文を省略することです。API は POST データを受け取りません ( https://www.varnish-cache.org/trac/ticket/652 )。これが私たちが立ち往生しているところです。

主な問題は、図で達成しようとしているフローをどのように実現するかということです。理想的には、varnish をリバース プロキシおよびキャッシュ メカニズムとして使用し続けることですが、別のリバース プロキシをセットアップし、varnish をプロキシと API の間のキャッシュ サーバーにする必要がある場合でも、問題はありません。あなたの助けは大歓迎です！

4

1 に答える 1

0

お気づきのように、Varnish は (現在) リクエストまたはレスポンス ボディをほとんど処理していません。ただし、ヘッダーにはかなり適しています。

ヘッダーだけで認証を行うのに十分な情報があるように、アプリケーションを変更できますか?

認証トークンが埋め込まれた URL に POST するか、リクエスト ヘッダーを追加します。(X-auth-token: foo)

また、再起動を使用する代わりに、 CURL VMODを使用して認証サーバーを呼び出すことをお勧めします。VCL をより読みやすく、デバッグしやすくします。

于 2013-02-13T08:22:23.747 に答える