2

ユーザーがログインする前に、アカウントをアクティブ化してほしい。登録後に、次のようなアクティベーションリンクを含む電子メールが送信されます。

http://www.blabla.com/activate.php?email=blabla@blabla.com&token=Aisd23uNMAu53932asdDasd82AS

もちろん、誰かがログインするたびに、そのユーザーが自分のアカウントをアクティブ化したかどうかを確認する必要があります。この問題を解決する2つの方法を考えることができます。どちらか、ユーザーが次のようにアクティブ化するたびに空に設定される「users」テーブルに追加の列があります。

-----------------------------------------------
| id | username | password | activation_token |
-----------------------------------------------
| 1  | user1    | blabla   |                  |
-----------------------------------------------
| 2  | user1    | blabla   | asd232DA34qADJs2 |
-----------------------------------------------

次に、ユーザーがログインするたびに、ユーザー情報とともにactivation_tokenを抽出します。または、アクティベーショントークンのみを含む別のテーブルを作成し、ユーザーがログインするたびに「users」テーブルに結合することもできます。

--------------------------------------
| id | account_id | activation_token |
--------------------------------------
| 1  | 37         | dsad2428491dka98 |
--------------------------------------
| 2  | 2          | asd232DA34qADJs2 |
--------------------------------------

では、どちらが最も効率的でしょうか？御時間ありがとうございます。

編集：すべての素晴らしい応答をありがとう

4

8 に答える 8

4

個人的には、この2つを組み合わせて…

-------------------------------------
| id | username | password | status |
-------------------------------------
| 1  | user1    | blabla   | 1      |
-------------------------------------
| 2  | user1    | blabla   | 0      |
-------------------------------------

ステータスは、TINYINT(1)無効化されたユーザーの場合は 0、有効化されたユーザーの場合は 1 のフィールドです。そうすれば、ユーザーの「ステータス」をすばやく知ることができます...

次に、トークンを別のテーブルに保存します（既に持っているのと同じように）... そうすれば、アカウントをアクティブ化しないときに参加したり、文字列列をチェックしたりする必要はありません...

于 2010-08-03T15:25:22.323 に答える
1

最初のオプションを使用しisactivatedて、テーブルに列を追加しUSERSます。

別のテーブルは必要ありません。これは 1 対 1 の関係です。

于 2010-08-03T15:24:07.053 に答える
1

別のテーブルではなくユーザー テーブルにトークンを格納すると、クエリごとにトークンを結合する必要がなくなり、少し速くなります。

また、userIds を保存せず、そのトークン テーブルの新しい Id を作成します。これにより、データ ストレージが節約されます。

于 2010-08-03T15:24:36.153 に答える
1

デフォルトで 0 に設定されている整数フィールド、Activated を使用します。誰かが認証を試みると、Activated アカウントのみを検索します。あなたが説明したように、認証トークンを別のテーブルに保存します。

于 2010-08-03T15:24:48.160 に答える
1

関係が 1 対 1 の場合 (たとえば、アクティベーション テーブルにはアカウント ID ごとに 1 行がある場合)、完全に正規化された 2 テーブル アプローチを行うのはやり過ぎです。

どちらのアプローチでも大きな問題はありませんが、1 テーブルの方が簡単です。

2 テーブル アプローチを使用する場合は、「アクティブ化された」yes/no フラグをユーザー テーブルに格納する必要があるため、ユーザー ログインのために 2 番目のテーブルに参加する必要はありません。

于 2010-08-03T15:26:31.530 に答える
1

アクティベーション トークンが「ここをクリックしてアカウントをアクティベートする」リンクを検証するためだけに使用され、二度と使用されない場合char(32)、1 のフィールド (またはそれが何であれ)を格納するユーザー テーブルのスペースを無駄にする意味はありません。時間の使い方。ユーザーがクリックしてアクティブ化するときに、アカウントのアクティブ化スクリプトが参照できる別のテーブルにアクティブ化トークンを配置します。アクティベーションが完了したら、別のテーブルからトークンのレコードを削除できます。

ユーザー テーブルに「is_activated」ブール値/ビット フィールドを配置して、ログイン スクリプトがログイン プロセス中にチェックできるようにします (フィールドが null/false の場合は、「ねえ、まだアクティブになっていません」というエラーを出力します)。

もちろん、最近のディスク容量は安価です。それぞれが 32 文字のアクティベーション トークンを持つ 100 万人のユーザーでさえ、32 メガバイトのスペースを「浪費」するだけです。テラバイト ドライブが 100 ドル未満の場合、これはディスクの 0.00305% であり、基本的に 0.00 ドル (0.305 セント) のコストです。

于 2010-08-03T18:10:17.697 に答える
0

私の意見では、アクティベーションコードをusersテーブルに保存する代わりに、デフォルトでフラグをオフにしておいてください。ユーザーがアクティベーションリンクをクリックしたら、テーブルを更新してフラグをオンにします。

ログインする前に、フラグがオンになっているかどうかを確認してください。フラグがオフの場合、ユーザーはアクティベーションリンクをクリックしていません。次に、ユーザーにエラーメッセージを表示できます。

フラグがオンの場合、ユーザーは正常にログインできます。

于 2010-08-04T10:42:13.273 に答える
0

アクティベーション トークンを DB に保存する必要はないと思います。md5('users@email' . 'secret') のようなものは問題なく動作します。ユーザーステータスについては、他の人に同意します。ユーザーテーブルで別の専用の「ステータス」列を使用します。追加の利点は、この列が他のステータスも保存できることです (例: "banned" ;)

于 2010-08-03T15:52:05.290 に答える