以前に「ソフト」登録、遅延登録、または「邪魔にならない」登録について読んだことがあり、それからOpenIDとそれが解決策のように見えるすべてのものを自分で決めました。 しかし、現在のプロジェクトに取り組んでいるとき、私はこれが私にはまったく合わないことに気付きました。
就寝直前に決定が下され、今朝実施されました。 満足しました。
しかし、まず最初に。
そもそも、OpenIDが私に合わなかったものです。 すべてがシンプルです。 もちろん、このプロジェクトのサイトのターゲットオーディエンスは全員、まともな人々であり、ほとんどがソーシャルネットワーク（森林管理者）から遠く、必要なアカウントをまったく持っていないか、システムを選択する際に必要なものを理解するのが難しい場合があります登録できます。 したがって、OpenIDではなくシンプルなものが必要です。
ダチョウと首についての素晴らしいソビエトの漫画を誰もが覚えていると思います。ダチョウと首は、主なものは脚または翼であると主張しました。 彼らの議論は、「単純化された」登録と「完全に単純化された」登録のどちらかを選択しようとすることを連想させます。 だから、主なものは脚や翼ではなく、尾、我々の場合、認可です。 登録がどれほど単純であっても、将来ユーザーに許可できるデータは重要です。 その結果、ユーザーは自分が既に「登録」していることに気付かない場合があります。
アイデアの形式化
新しいセッションはそれぞれ新しいユーザーです。 同じブラウザと同じコンピュータから1日でログインした場合、これが同じユーザーであることは明らかです。1か月の場合は同じユーザーのままです。 これまでのところ、これは完全な承認には少なすぎますが、威勢のいい問題が始まっています。 訪問者とサーバー上のセッション自体によって、Cookie内のセッション識別子の保存時間を増やすことができます。 信頼性を高めるためにも必要だと思います。
突然、ユーザーがサイトのどこかにメールを入力する必要がある場合、次のとおりです。 -このユーザーは失われません。 任意のブラウザおよび任意のコンピューターから電子メールアドレスを入力することを提案することで、彼が本人であることを確認できます。 しかし、許可する前は、彼と私たちのサイトとのやり取りの履歴は利用できません。
しかし、ユーザーが自分自身を認証したい場合、パスワードをメールに送信します。
これで、すべてのルールに従ってユーザーが登録され、このユーザーのロイヤルティは「標準」スキームに従って登録されたユーザーのロイヤルティよりも大幅に高くなります。
アイデアの実装
私のバージョンを提供します。
訪問に関する統計を収集するモジュールが既にエンジンにあります。 現在では、セッション識別子、ユーザー識別子（デフォルトではゲスト識別子）、および要求に応じたすべての情報を単一のテーブルに保存します。 統計テーブルからユーザーIDを削除し、2つのフィールドを持つ新しいテーブルを作成します。
- セッション識別子。
- ユーザーID
次の場合、このテーブルに情報を入力します。
- 新しいユーザーを作成します。
- 現在のユーザーを識別または許可した後、現在の名前のないユーザーですべての行を更新します。
したがって、統計は識別および承認プロセスとは完全に独立して保持されますが、ユーザーが登録されるまでの時間に関係なく、すべてのユーザーに対して統計のほとんどすべてを使用できます。
将来、OpenIDをこのスキームにリンクする際に問題はありません。
未入力フォームを保存するメカニズムを実装するには、次の表を作成します。
- セッション識別子。
- フォームタイプの識別子。
- フォームに関連する最後のシリアル化された投稿リクエスト。
また、最も頻繁に入力される値を置き換えることも考えていますが、これは後のことです。
あなたはまだそのような有用なことをすることができます。 現在のユーザーの機密情報があり、彼のメールを既に知っている場合、「注文の履歴（質問、苦情、リクエストなど）」というテキストを含むリンクを目立つ場所に配置します。承認」。 そのため、ユーザーは、ユーザーが彼を認識し、覚えていることを理解します。
おわりに
だから、私にとっての登録の問題はもはや問題ではありません。 私のソリューションがあなたのプロジェクトに役立つことを願っています。
PS首、ダチョウ、トカゲについての素晴らしい漫画をここで見ることができます 。
UPD：
標準の「明示的な」登録も実装されています。 パスワードの変更とパスワードの回復が可能です。
UPD2：
提案されたメカニズムの範囲私は、その複雑さと規模に関係なく、あらゆるリソースを見ています。
説明します。 リソースのすべてのユーザーアクションは、3つのカテゴリに分類できます。
- 誰がそれを行うかは関係ありません。人またはロボット（ページをたどり、場合によっては何か）。
- この場合の保護は必要ありません。
- このアクションは、サイトにアクセスしたすべてのユーザーが利用できます。
- これは人によって行われることが重要です（通常のサイトへのコメントと、そのような単純なアクション）。
- 保護は一般的なキャプチャです。
- このアクションは、認証されたすべてのユーザーが利用できます。 私たちの場合、キャプチャを処理できれば、サイトにアクセスする人は誰でも、ロボットであってもです。
- これは人によって行われ、このアクションの責任を負うことが重要です（注文、投稿、深刻なリソースへのコメント）。
- 保護-メールによる確認。
- 検証済みの電子メールなしで認証されたユーザー（アクセスできるのは1回だけであることは明らかです）および認証されたユーザーがアクセスできます。
承認されたユーザーであれば、すべてが明確になります。 これは標準的な状況です。
特定されたユーザーについての多くの話。
ユーザーはサイトに自分の電子メールアドレスを入力したことがありませんが、識別されていると見なされ、カテゴリ1および2のアクションを必要な回数実行できます。 また、彼はカテゴリ3の任意のアクションにアクセスできますが、一度だけアクセスできます。 このアクションが正常に完了すると、そのようなユーザーは完全に登録され（サインはプロファイルに確認済みの電子メールが存在する）、次回は許可なしにカテゴリー3アクションを実行できなくなります。例：ママ）。 当然、ユーザーには通知でこれが通知されます。 当然、彼には「終了」ボタンがあります。
UPD3：
問題状況とその解決策
私は、確認済みのメールまたは電話を持たない特定のユーザーがサイトでカテゴリ2のアクションを実行しましたが、セッション中に別の100,500人のユーザーがサイトでカテゴリ2のアクションを実行しました。
トピックから、サイトは1人のユーザー、つまり、私はこれらすべての100501カテゴリ2アクションをコミットしたと考えることになります。
必要な修正。 確認済みの電子メールまたは電話（特定のサイト用に事前に選択されているリスト）のないユーザーの個人データが大幅に変更された場合、これは新規ユーザーです。
カテゴリ2アクションの各タイプの個人データのリストは、原則として、特に異なるサイトで異なる可能性があり、それぞれの場合に個別に選択する必要があることに注意してください。
この事例の詳細については、 Nail13に感謝します 。