0

ソーシャル サイトの活動追跡システムの作成。ログインからログオフまでのすべてのユーザー アクティビティが追跡されます。これは、最初の使用例がユーザーのログインであることを意味します。すべての活動は同じ形式であるため、1 つの活動を追跡する方法を理解したら、すべての活動のケマを作成できます。現在、ログインには次のような手順があります。

私が持っている 2 つの解決策:
アクティビティ 1: ユーザーがログインを試みる
アクティビティ 2 A: ユーザーが正常にログインした
アクティビティ 2 B: ユーザーがログインに失敗した。
アクティビティ 2 BA: パスワードが無効なため、ユーザーが
ログインに失敗しました。 アクティビティ 2 BB: アカウントがロックされたため、ユーザーがログインに失敗しました。

また

アクティビティ 1: ユーザー ログイン - 結果 = 合格または不合格、不合格の場合は理由 = 理由の flag_id。

したがって、スキーマを作成する必要があります。今のところ、次のようにしています:
activity_id
object_id (fk)
session_id (fk)
user_id (fk)
flag_id (fk)
created_dt
friend_id (fk)
結果 (合格/不合格)

もちろん、これは進行中の作業です。

4

1 に答える 1

1

この要件は、ログイン失敗の理由を含めるために、システムへのログイン試行の監査が必要であることを単に述べているだけのように思えます (まあ、簡単に述べようとしています)。テーブルは次のようになります。

LoginAudit
  ID (some kind of primary key, whatever your standards are)
  UserID (FK to whatever table holds users, or whatever uniquely identifies a user)
  LoginTime (time stamp of attempt)
  IsSuccessful (bit, true or false, was the login successful?)
  Status (FK to a table of known statuses, or just the status itself for a flat de-normalized structure, indicating "success" or a reason for failure, such as "invalid password" or "account locked")
  (more relevant data, such as user's IP or location, etc.)...

これは書き込みの多いテーブルになり (インデックスに注意してください)、データを変更するべきではありません。更新などを防ぐために、いくつかのトリガーを配置することをお勧めします。

余談ですが、これは言うまでもありませんが、念のために言っておく必要があると思います。ここに保存するときに、ログイン失敗の理由をユーザーに提示しないようにしてください。ユーザーに表示されるのは、ログインが失敗したことだけです。ログインが失敗した理由は、攻撃者がシステムを操作するために使用できる追加情報を提供します。

于 2010-12-26T13:29:36.887 に答える