Q&A
回答ありがとうございます。
どちらが正解というよりは展開するサービスによって
使い分けた方がいいということがわかりました。
参考にさせてもらいます。
WEBサービスにユーザ登録機能を実装します。
WEBサービスによってユーザ登録までの流れはいくつかあると思いますが、
以下の2パターンならどちらが望ましいでしょうか？
＊＊＊＊パターン１＊＊＊＊
入力画面(メールアドレス、ユーザ名、パスワードなど)
→POST
→メアドの重複など、エラーがなければ登録完了
→入力したメアドにリマインダー送信
＊＊＊＊パターン２＊＊＊＊
入力画面(メールアドレスのみ)
→POST
→入力したメアドにトークン付きのURLを記載し送信、セッションにも登録
→トークンをキーにセッションが存在していればクリック時に入力画面表示(ユーザ名、パスワードなど)
→POST
→登録完了
→入力したメアドにリマインダー送信
特に、初期入力画面で項目をメアドのみかそれ以外を含むかで迷っています。
アドバイスお願いします。
～追記～
みなさん回答ありがとうございます。
結論としてパターン２ベースで以下の流れで行うことにしました。
入力画面(メールアドレス、ユーザ名、パスワード)
→POST
→エラーがなければ入力したメアドにトークン付きのURLを記載し送信、キャッシュに登録
→URLクリック時、トークンをキーにキャッシュが存在していれば入力画面表示(ユーザ名、パスワード)
→POST
→ここでDBに登録し、リマインダー送信(パスワードに関しては難読化して登録)
→登録完了画面表示
回答7件
0
私ならパターン2を選びます。メールの生存確認が同時に行えるため、リマインダーなどの送信が失敗する可能性が減ります。
また、メールに記載されたトークンからの入力画面で、「パスワード」のみを入力させ、ログインにはメールアドレスとパスワードというのが、抵抗無くするっと登録できます。
で、ログインパスワードを決定したらアカウント設定ページに飛び、必要な情報を入れると言う流れを私なら考えます。
投稿2016/04/04 15:40
総合スコア69400
0
ベストアンサー
登録時に最初にメールアドレスだけを送るケースはあまり見かけないような気がします。なので、どちらかを選ぶならパターン1ですが、やはりメールアドレスの有効確認は必要だと思うので、パターン3として、
入力画面（メールアドレス、ユーザー名、パスワードなど）
→POST
→メールアドレス、ユーザー名の重複チェックなど
→エラーがなければ仮登録し、入力したメアドに確認のための文言とトークン付きのURLを送信
→トークン付きのURLを開く(GET)
→正式登録。確認画面
→登録したメアドにリマインダー送信
このように、最初の入力では仮登録とし、メールアドレスの有効確認（＝本人の最終的な同意）が取れた時点で正式登録というパターンが割と多いような気がします。
投稿2016/04/04 22:29
総合スコア5938
0
ステップを短くすれば脱落が減りますが・・私なら２です。
最近はメール以外での認証があるのと、アプリ化を視野にいれる（最初の部分だけアプリ内のブラウザで処理する）ことを考えると、メールだけ分離しておいたほうが、あとあと便利だからです。
投稿2016/04/04 17:48
総合スコア234
回答ありがとうございます。
どちらが正解というよりは展開するサービスによって
使い分けた方がいいということがわかりました。
参考にさせてもらいます。
0
サイトの性格によって変わってくると思います。
ただメールを何度も経由する場合、その通信は平文(だったはず)になるので、セッションを維持する情報や個人情報の、メールでのやりとり回数は減らしたいと思ってしまいます。ですので「1」推し。
※「2」でもセッションは時限性でワンタイムでしょうし大丈夫だとは思います。
※必要な個人情報がメールアドレスのみとかなら、「2」が良さそうに思います。
私なら、「ユーザID,パスワード,メール,その他そのサービスが求める最低限必要な情報」を入力させて
問題が無ければ「ユーザID様登録が完了致しました。etc,覚えが無い場合はetc,登録情報に誤りが無いかユーザ情報ページにログインしてご確認ください。URL,etcetc」のようなリマインダを送信するかな...
投稿2016/04/04 17:35
総合スコア2068
回答ありがとうございます。
どちらが正解というよりは展開するサービスによって
使い分けた方がいいということがわかりました。
参考にさせてもらいます。
メールの文面も参考人させてもらいます。
0
やはり、どのようなサービスなのかによるでしょうね
Ａ）多くのユーザを獲得したい
→ １
Ｂ）有効なユーザに絞りたい
→ ２
ざっくりとこんなところでしょうか
Ａの場合は、
・入力が１度で済みユーザの負担が少ない
・つくりがシンプルで開発面でも保守面でも効率がよい
といった利点があげられます
ユーザは普通、あえて使われていないメールアドレスを入力しようとはしません
そのサイトが提供するサービスが受けたくて登録するのだから、ほとんどの人が受信可能なメールアドレスを入力します
しかし、悪意を持った人が故意に大量ユーザ登録をすることも考えられます
また得られるサービスの内容が、ユーザ登録の手間よりも価値があればユーザは一生懸命に手続をしてくれるでしょう
それならば Ｂ でよいと思います
Ｂの場合、最初の入力では仮登録とし、メールアドレス向けにワンタイムＵＲＬを送り、正式登録のための初回ログインをお願いします
一定期間、初回ログインが無ければその仮登録は削除します
最低限こうしておけば、無差別に登録するような輩がいても無効なユーザをある程度除外できます
どちらの場合でも、最後に正式登録したことを通知するメールを出すかどうかは必須ではないと思いますが、正式登録した旨の通知、サイト入り口のＵＲＬ、登録解除用のＵＲＬ、問い合わせ先、が一緒に書かれていれば、なにかあっても「このメールを残しておけば大丈夫」と安心するでしょう
以上ご参考まで
投稿2016/04/05 00:41
総合スコア3111
> ユーザは普通、あえて使われていないメールアドレスを入力しようとはしません
> そのサイトが提供するサービスが受けたくて登録するのだから、ほとんどの人が受信可能なメールアドレスを入力します
使わないメールアドレスを入力される事よりも、自分のメールアドレスを間違えて入力されることが案外多い印象があります。なので間違い入力の対応策としては空メールを送ってもらうのが現実的なのかもしれません。
回答ありがとうございます。
確かにメアドの入力ミスはありますのでいずれにせよリマインダー送信は必要になりそうですね。
どちらが正解というよりは展開するサービスによって
使い分けた方がいいということがわかりました。
参考にさせてもらいます。
0
メールアドレスもらって何がしたいのですか？
ビジネスの戦略上他人に教えられなくても明確にあるのであれば2は魅力的ですが、
1のほうが圧倒的にサービス利用までの障害が少なく、無料ユーザーを集めるには有利です。
投稿2016/04/04 22:43
総合スコア21158
回答ありがとうございます。
> メールアドレスもらって何がしたいのですか？
思いのほかというか、今までで一番回答が得られたのでちょっと申し訳ないですが、
自身用にユーザ管理機能を含めたWEBツールのフレームワークを作成し、今後の業務に役立つ知識を取り入れることが目的です。
なので集客の戦略などはまだ考えていません。
ただし、独自ドメインを取得して公開する予定なので間違いのないシステムを開発しようと思っています。
返信ありがとうございます。
個人情報は＝リスクなので、何がしたいかは大事だと思ってます。
私は個人でWebアプリを作るときに「＝リスク」を最も意識して、自分サーバ上のDBに持たせないためにOAuthを採用しました。
githubやbitbucket、trelloのような海外製Webアプリはメールアドレスとパスワードの2つだけですぐに始められるケースが多いように思えます。
対エンジニア、ビジネスマン、学生…サービスの性質やユーザーの性質でいろんな最適解があると思います。
私もまだまだ若輩者ですが、お互い頑張っていきましょう。
ユーザ情報をテーブルに持たずにsnsなどのログインapi機能で代用するということでしょうか？
テーブルに持たせないという考えはなかったので勉強になります。TwitterOauthとかでしょうか？
仕組みや使い方がわからないので調べてみます。
そうです。
様々なWebアプリのTwitterアカウントでログインみたいなあれです。
複雑ではあるのですが、一意の公開用IDを受け取る事が出来ます。
PHPやJava、Node.jsでは公式でライブラリを配布してくれるものもあるので挑戦してみると面白いです。
Usersテーブルのカラムを「id, provider, provider_id」等のようにしておく事で、
サーバーのDBに名前もメールアドレスもないような運用も可能です。
回答ありがとうございます！
oauthの方はまだ調べられてないですが、Twitter、フェイスブックからのログインも可能にすることにしました。
とりあえずは自身のDBで管理する機能を実装するのでそれが済んだら別途質問するかもしれません。
0
terateilの場合はパターン１のようですね。
1回の入力ですべて終わるので好みの問題かもしれませんが①の方がすっきりしていて
簡潔なので良いと感じております。
投稿2016/04/04 15:35
総合スコア133
フェイスブックもパターン1に近いようでした。
実装もパターン1の方が楽そうですが、kei344さんのおっしゃる通り、メールの生存確認は送信しないとわからないのでパターン2の方が間違いが少ないような気がします。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/04/04 16:09
2016/04/04 16:41
2016/04/04 16:46
2016/04/05 04:53