2013-03-06 13 views
8

"いいえ、一番良い答え"の問題を避けるために、私は最良の方法ではなく、セッションを処理する標準的な、あるいは最も一般的な方法を尋ねます。 Tornadoフレームワークを使用します。つまり、サードパーティの認証(OAuthなど)を使用していない場合は、ブラウザに安全なCookieを持つ独自のUsersテーブルが必要ですが、サーバーに保存されているほとんどのセッション情報は、これを行う最も一般的な方法は?私はRedisを使っている人もいるし、普通のデータベース(MySQLやPostgresなど)を使っている人もいるし、memcachedを使っている人もいる。竜巻でのユーザーセッションを処理する標準的な方法

私が開発しているアプリケーションには、一度に何百万人ものユーザーがいないでしょう。しかし、やや複雑な認可スキームを最終的に得る必要があります。私が探しているのは、一般的なトルネードコミュニティとは違う道を行く "奇妙な"ことをしないことです。なぜなら認証と承認は、必要なものですが、私たちの製品の中核であり、私たち自身を差別化すべき場所ではありません。だから、私たちはこの点でほとんどの人(トルネードを使っている人)がやっていることを探しています。それゆえ、それは客観的に真の答えである(理論的には)問題だと思います。

理想的な答えは、もちろんコード例を指します。

答えて

8

ステートレスであるように設計されたトルネードは、そのままの状態でセッションをサポートしていません。

安全なCookieを使用して、user_idなどの機密情報を保存します。 重要な情報を保存するために標準Cookieを使用します。

大きなオブジェクトを格納する場合 - 標準スキームであるMySQL + memcacheを使用します。ここで

+0

クライアント側のCookieを使用する場合は、「安全」なCookieであっても十分注意してください。たとえば、ユーザーが信頼できるサーバー以外の有効なCookieにロールバックした場合はどうなりますか? [クッキーの代わりにサーバーにセッションを保存する理由](https://stackoverflow.com/questions/3948975/why-store-sessions-on-the-server-instead-of-inside-a-cookie)を参照してください。 – JasonCG

+1

@JasonCG、はい。だからこそ、世界はJWT(https://jwt.io/)にアップグレードされたのです。また、私は問題の答えに同意します - あなたはクッキー/トークン/ etcにユーザーのバランスを保存すべきではありません。バランスが非常に重要なので、最大限の一貫性が必要です。 –

13

は、他のマイクロフレームワークが(例えばCherryPyに、フラスコ)セッションを処理思える方法は次のとおりです。

  1. session_idや他のどんな分野は、セッションごとに追跡したいと思うでしょうが保持するテーブルを作成します。一部のフレームワークでは、この情報をユーザー単位でファイルに格納するだけで済みますし、メモリに直接格納することもできます。アプリケーションの規模が十分小さい場合は、これらのオプションも考慮することができますが、データベースは自分で実装する方が簡単です。
  2. リクエストが受信されたとき(RequestHandler initialize()機能と思います)、session_idクッキーがない場合、ランダムジェネレータを使用してセキュアなセッションIDを設定します。私はトルネードで多くの経験がありませんが、安全なクッキーを設定するのが便利なはずです。そのsession_idと関連情報をセッションテーブルに格納します。ログインしていなくても、すべてのユーザーにセッションが与えられることに注意してください。ユーザーがログインすると、ログインした状態(およびそのユーザー名/ユーザーIDなど)をセッションに添付する必要があります。
  3. RequestHandler initialize関数で、session_idクッキーがある場合は、必要なセッション情報をDBから読み込み、独自のSessionオブジェクトを作成して、そのリクエストハンドラのメンバ変数として保存します。

セッションは一定量の非アクティブな時間が経過すると有効期限が切れるはずですので、それもチェックしてください。 「私を覚えている」タイプのログインが必要な場合は、セキュアなクッキーを使用してその旨を伝える必要があります(OWASPでこれを読んでできるだけ安全であることを確認してください。また、Tornadoのsecure_cookieこれでタイムアウトしたセッションを受信すると、新しいセッションを作成し、古いセッションから関連する情報を転送することで、新しいユーザーを再認証することができます。

3

セッションの重要な問題は、セッションを保存する場所ではなく、セッションをインテリジェントに期限切れにする方法です。セッションが保存されているかどうかにかかわらず、保存されたセッションの数が妥当である限り(すなわち、アクティブなセッションと余剰の一部のみが保存される)、このデータはすべてRAMに収まり高速に処理される。古いジャンクが多い場合は、予期しない遅延(セッションをロードするためにディスクを叩く必要がある)が予想されることがあります。

2

この目的で竜巻に直接組み込まれているものはありません。既に他の人がコメントしているように、Tornadoは非常に高速な非同期フレームワークであるように設計されています。それは設計によって痩せている。ただし、独自のセッション管理機能をフックすることは可能です。セッションコンテナを作成または取得するプリアンブルセクションを各ハンドラに追加する必要があります。セッションIDをクッキーに保存する必要があります。厳密にHTTPSでない場合は、安全なCookieを使用することになります。セッションの永続性は、Redis、Postgres、MySQL、ファイルストアなどの任意のテクノロジにすることができます。

Tornadoのセッション管理を提供するGithubプロジェクトがあります。たとえそれを使用しない場合でも、独自のセッション管理をどのように構築するかについての洞察が得られます。 Githubプロジェクトはdustdevilと呼ばれています。完全開示 - 私たちはこれを数年前に作成しましたが、今日は非常に使いやすく、積極的に使用しています。

関連する問題