メールを検証すると、自動的に誰かがアプリケーションにサインインする必要がありますか？
Webアプリケーションで新しいアカウントにサインアップする場合、確認メールを送信するのが標準です。私は検証メールの賛否両論には入りたくありません。
検証メールを受信し、検証リンクをたどると、アプリケーションは通常、メールアドレスが検証されたことを知らせる画面を表示します。その時点で、2つのオプションのうちの1つがあります。
- ユーザーが自分のユーザー名とパスワード（またはそのような組み合わせ）でアプリケーションにサインインできるようにします。
- 適切なアカウントを使用してアプリケーションにユーザーを自動的にサインインし、アプリケーションで実行していることを何でも開始できるようにします。
オプション1の方がセキュリティが優れているように見えますが、オプション2の方がユーザーは行うことが少なく、UXが優れています。
初期ユーザーエクスペリエンスを向上させるためにセキュリティのトレードオフ（オプション2）を行うのはいつ正当化されますか？
番号1は私のペットのおしっこの1つです...特にメールをすぐに確認する傾向があるため、フローは記入されますform>メールを確認する/確認をクリックする>認証済みユーザーとしてサイトに戻るそれを行った後で再度ログインする必要がある場合は、壁にぶつかります！少なくとも、同じセッションで自分のメールアドレスを確認しているユーザーがアカウントを作成できるように、ログインのみを許可してください。
それ以外の場合（またはセッションデータが不明確な場合）には、再度ログインするように要求することで問題ありません。
考慮すべきことの1つは、サービスを使用する前に、ユーザーにメールアドレスの確認を本当に必要とするかどうかです。私の組織では、ユーザーがサインアップしてすぐに使用を開始できるアプリケーションがいくつかあります。彼らは電子メールの確認メッセージを受け取りますが、サービスの使用を開始する前に実際に確認を完了する必要はありません。これは、別のユーザーを偽装することに実質的な影響がない場合に最適に機能します-ソーシャルアプリには推奨しません。たとえば、 FacebookのサインアッププロセスをTwitterのサインアッププロセスと比較 ... Facebookでは、サービスを使用する前にメールアドレスを確認する必要があります。 Twitterを使用すると、サービスにすぐにアクセスできます（ただし、実行できることには制限があります）。
他の1つのオプションは、電子メールの確認を強みとして活用することです... Web時間管理ツール Nozbe ユーザーが登録フォームに入力するときに、名前/電子メールアドレス（パスワードなし！）の入力のみを要求します。 、ユーザーがメールアドレスを確認すると、アプリに戻ってパスワードを選択します。このプログレッシブエンゲージメント方式は、（明らかに）成功しています（例： X And All ）。
複数の人がメールを共有するという問題があります。夫と妻はしばしばこれを行います。オプション1を使用すると、誰でもアカウントを検証できます（大したことではありません）が、電子メールにはアクセスできますがパスワード情報にはアクセスできないため、他の人のアカウントにはアクセスできません。
自動的にログインするもう1つの問題は、通常のパーソナルコンピューター以外のブラウザーから検証メールをチェックしている可能性があることです。彼らは自分の電話、仕事用PC、さらには公共図書館のマシンでさえそれを開いたかもしれません。このマシンは、セッションの存在を許可している限り、ログインしたままになります。
Facebookのようなサービスの場合、これはこの他のコンピューターに非常に長い間機密情報を提供する可能性があります（facebookは何日もログインしたままにします）。 ユーザーは多くの場合、「ログアウト」する必要があることを認識していませんそのようなサービスも同様です。したがって、人々がFacebookアカウントをログインしたまま職場、学校、またはデモ用のラップトップやスマートフォンにログインしたときに、Facebookアカウントの多数のストーリーが「ハイジャック」または「ハッキング」されます。
ユーザーはWebサイトからログオフしないことが多いため、デフォルトでログオンすると、システムの状態（ログイン中）を直接制御できず、その方法がわからない（危険な）状況に簡単に陥る可能性があります。状況を修正するために彼らはそのような問題が存在することをまったく知らないかもしれません。
理想的な状況は、一般的に2つの例の中間になると思います。もちろん、いくつかのサイトは多かれ少なかれセキュリティに集中する必要があります。
一般に、その後の2つのケース、即時アクティブ化と遅延アクティブ化があります。メールリンクがすぐにクリックされた場合、ユーザーに再度ログインするように強制する必要はほとんどありません。ただし、翌日または2日までリンクをクリックしない場合は、ログインが必要になる可能性があります。
他の答えは長くて包括的なので、2セントを投げます：OpenIDを使用！
シンプルで、開発者との両方のユーザーにとって簡単です。StackExchangeサイトで使用され、パワーユーザーとダミーの両方を幸せにします。彼らはそれを期待したか、そうしなかったからです。何十億ものアカウントがあり、それぞれのログインを構成しなければならないのはとても残念です。
答えは何もないと思います。まあ、私は本当に電子メールの検証は電子メールの検証として扱われるべきであることを意味します。
ユーザーがすでにアクティブ/認証済みセッションを持っている場合は、それを許可します。そうでない場合は、サインインさせます。
アプリケーションによって異なります。 ＃2はシームレスなエクスペリエンスを実現しますが、ユーザーに関する機密情報が保存されている場合は、＃1を使用することをお勧めします。 「機密」とは、メールアドレスの保存から、ユーザーが受け取る情報の種類に関する設定まで、すべてを意味します。
私は経験から話します-私の姓と名を合わせた@gmailアドレスを持っています。私の名前はかなり一般的です。そのため、ミドルネームの頭文字または末尾の数字が含まれていると思われる人宛のメールをよく受け取ります。他の人宛の正確な「アカウント確認」メールを受信しました。そして、これはの人々が自分の電子メールアドレスを常に間違って入力したために起こりました。 ＃2のアプローチを使用しているシステムからメールを受信しましたが、アクセスできないはずの詳細を確認できました。
＃2を使用する場合は、登録フォームでメールを2回入力してから通常の検証を実行する必要があることを確認してください。