5

私は現在、スタック オーバーフローのような非常にデータベース指向のサイトを作成しています。私の質問は、複数のサーバー間を移動するセッションを処理する方法です (自動スケーリングに AWS サーバーを使用する予定です)。

現在、スケーラビリティと速度の目的でフォーム認証を使用すべきではないと考えています。代わりに、sessionID、UserID、ExpDate、CreateDate、IP、Status('LogedIn', 'LogedOut', 'Expired') という情報を格納する、sessions というデータベースにテーブルを作成します。

私の最大の懸念は、Cookie の観点から見たセキュリティであり、多くのサーバーを実行しているときにボトルネックのシナリオを見た経験がないことです。

あなたの洞察を教えてください。また、他の人やスタック オーバーフローがこのジレンマにどのように対処しているか知りたいです。

参考までに: 同じ理由で、Entity Framework の代わりに PetaPoco を使用しています。そうすることで約 600 ミリ秒を削減できたからです。

ご協力ありがとうございました！

4

2 に答える 2

2

フォーム認証の使用に関するスケーラビリティの問題は認識していません。基本的に、認証トークンを Cookie に暗号化し、Cookie は要求ごとにサーバーに提示されます。インプロセス セッションの代わりに Cookie を使用すると、特定のサーバーに関連付けられていないため、スケーラビリティが可能になります。

暗号化はサーバーに保存されている machineKey 値を使用するため、暗号化を破るには machineKey を取得する必要があります。

一般に、私は独自の承認を実装しないように努めており、代わりに、テスト済みのすぐに使えるソリューションに固執するようにしています。

セッション ストアを使用するアプローチでは、Cookie を使用して、セッション ストアへの何らかのポインターを保存する必要があります。実装によっては、この情報を簡単に推測して、簡単に他人になりすますことができます。

編集：

AWS で実行しているため、ElastiCache を利用して DB ヒット数を減らすことをお勧めします。

于 2013-08-06T20:48:57.717 に答える
1

キャッシングの観点から、StackOverflow が Redis を使用して構築されたことを知っています。

Stack Exchange Network の構築に使用されるツールとテクノロジーを確認してください。.

于 2013-08-06T20:42:26.150 に答える