2

そのため、通常、私が扱っている大規模な Web サイトでは、セッション情報をデータベースに保存して、Cookie を簡単に複製できないようにする必要があります。

フラスコログインを使用すると、token_loader を使用して、たとえばトークンを ID にマッピングするためにセッションテーブルを照会する関数を実装する方法があります。

ただし、これは、セッション テーブルがユーザー テーブルと同じサイズになることを意味します。

id = db.Column(db.Integer, primary_key=True)
token = db.Column(db.String(250), unique=True)
uid = db.Column(db.Integer, unique=True)


@login_manager.token_loader
def token_load(token):
    return User.sessions.first().token

ユーザー テーブル情報で 8 MB がいっぱいのサイトを見たことがあります。たとえば、サイトは Drupal のセッション テーブルの行で詰まってしまいます。この方法でトークンを保管するのは賢明ですか? トークンの値を伝える各ユーザーの行だけですか?

基本的には、実際にログインするのではなく、Cookie を持つユーザーを識別するためのパスワード テーブルのようなものです。

フラスコログインのどこかでこれの実装を見た人はいますか?

4

2 に答える 2

1

Usersテーブルの追加フィールドを使用します。これにより、データが別のテーブルに複製されるのを防ぐことができます。IDとトークンだけをそこに保存するのであれば、別のテーブルを用意する意味はありません。ただし、さらに情報を追加する予定の場合（トークンが作成されたとき、後でトークンをより安全に検証するためのその他の情報、トークンからのIPアドレスが生成された、またはその他）、もちろん別のテーブルが必要になります。私の2c:)

于 2012-12-02T07:40:15.090 に答える
0

物事を過度に複雑にしている可能性があると思います。Cookie ではなくサーバー側に保存されたセッションを使用する場合は、redis などを使用してセッションを保存することもできます。以下の例を使用して、独自のセッション インターフェイスを作成するだけです。

http://flask.pocoo.org/snippets/75/

さて、「remember me」を 365 日間使用したい場合は、flask アプリでこれを行うだけです

from datetime import timedelta
app.secret_key = 'some secret random string'
session.permanent = True
app.permanent_session_lifetime = timedelta(days=365)
于 2012-12-03T17:14:22.513 に答える