3

Azure で node.js を使用してアプリケーションの開発を開始しています。多くの異なる認証方法をサポートしたいので、認証を提供するために everyauth を使用しています。Azure にデプロイする予定です。私が抱えている潜在的な問題は、everyauth が connect.session ヘルパーを必要とすることです。複数のインスタンスを実行している場合、これは azure で機能しますか? または、別のセッション プロバイダーが必要ですか?

4

2 に答える 2

1

Azure で Node.js を使用したことはありませんが、次のようになります。

すべての認証

ドキュメントを見るeveryauthと、Windows Azure ACS に対して認証する方法があります。Setting up Windows Azure Access Control Service (ACS) Auth詳細については、readmeのセクションを参照してください。Azure自体で動作しないというメモはありませんので、Azureで使用できると推測できます.

接続-紺碧

connect-azureと呼ばれるプロジェクトもあり、これを使用しているように見えるconnect.sessionので、ここでも Azure で動作することを推定します。

Azure サポートに連絡する

すでにお客様である場合は、サポートに連絡してサポートを受けることができます。

試してみてください

したがって、Azure 環境のセットアップがある場合は、試してみる価値があると断言できます。

于 2012-02-16T16:46:32.390 に答える
0

少し前に聞いたのですが、とにかく答えてみようと思いました。connect-sessionはセッションを維持するためにCookieに依存しているようです。Azureには、使用するものに応じて異なる負荷分散戦略があります。

  • WebRole / WorkerRole-LBにはアフィニティがないため、クライアントからの要求が異なるバックエンドインスタンスで終了する可能性があります。これにより、セッション管理接続が実行しているものはすべて破棄されます。これは、分散クラウドアーキテクチャの副作用です。バックエンドノードがダウンする可能性があるため、信頼できる唯一の情報源にしたくない場合です。したがって、あなたがしなければならないことは、connectのcookieストアを外部化し、すべてのバックエンドにそれを共有させる方法を理解することです。このように、どのバックエンドがリクエストを受信して​​も、セッションを認識します。

  • Webサイト-この場合、LBは実際にクライアント接続を特定のバックエンドインスタンスに固定しようとするため、Cookieベースのセッションは変更なしで機能する可能性があります。上記のように、フェイルオーバーを犠牲にしています。

于 2012-10-07T02:45:05.467 に答える