ユーザーが中断したところから再開できるようにする...ログインせずに（これは悪い形式ですか？）
私が取り組んでいるGrailsアプリがあり、ユーザーはかなり長いアプリケーションフォームに記入できます。私が与えられた要件の1つは、ユーザーにログインやアカウントの作成を要求しないことです。彼らがアプリに記入し始めると、私は彼らのアプリIDをセッションに保存して、ページからページへと記憶できるようにします。 1時間後、セッションは期限切れになります。彼らがアプリを完成させなかった場合、私は彼らに私たちを検討してくれたことに感謝するメールを送ります。
私がする必要があるのは、ユーザーが中断したところから再開できるようにすることです。これにより、ユーザーは、アカウントなしで、ユーザー名とログインの組み合わせなしで、アプリケーションを終了できます。
これを行うと思った1つの方法は、DBに格納されてアプリケーションIDにマップされる一意のID（adbce-13428-etace-etc ...など）を作成することでした。次に、「申請者への記入を続行する場合は、次のリンクをクリックしてください：myapp.com/continue/ {their_unique_id}」というリンクをメールで送信します。それをクリックすると、データベース内の一意のIDが検索され、アプリケーションIDが取得され、その情報がセッションに戻されて、アプリケーションを終了できるようになります。
私の質問は：これは悪い形ですか？デザインが悪いですか？セキュリティに悪いですか？どうして？
ローカルストレージを活用することもできますが、マルチユーザーまたはパブリックコンピューターに公開するリスクもあります。ユーザーが複数のコンピューターを使用すると、使い勝手が悪くなります。
電子メールソリューションでは、識別子に加えて特別なコード/トークン/パスワードを追加できます。つまり、識別子（UUID）とシークレットがあります。電子メールが危険にさらされた場合でも露出はありますが、UUIDがログやパケットキャプチャなどから危険にさらされた場合、設計されたチャネルを介してシークレットアクセスを許可することはできません。シークレットをURLの別のパラメータとして配置することもできますが、GETにあるため、URLがログに記録される場所に公開されるため、安全性は少し低くなります。
例えば。
ねえ、戻って http://somesite.com?your_app=12345 ......ページで次のコードを入力してXXXXを続行します
アプリケーションデータとシークレットは、一定期間が経過すると期限切れになり、削除されるか、ユーザーの観点からは表示されなくなるはずです（シークレットは時間の経過とともに秘密が少なくなる傾向があります）。
セキュリティに悪いかどうかは、入力する情報が「機密」と見なされるかどうかによって異なります。
他の誰かが自分のセッションIDを推測して（可能性は低いですが）、すでに入力したデータにアクセスできるかどうかは、申請者にとって重要ですか？ （データの機密性は重要ですか？）
申請者データを受け取っている組織にとって、パート1が1人で記入され、パート2またはパート3などが別の人で記入されている可能性があることは重要ですか？ （データの整合性は重要ですか？）
攻撃者が「後で保存して再開する」機能を実現するために使用されているプロセスを理解し、送信されたすべてのデータを収集できた場合、組織の評判に悪影響を及ぼしますか？彼らの評判は悪くなるでしょうか？
これらの質問のいずれかに対する答えが「はい」の場合、それは良い考えではないかもしれません。セキュリティのほとんどのものと同様に、それはすべてデータに関するものです。
私はmonkeymagicの答えと「データがすべてだ」という主張に同意し、EricGが提案したように間違いなく秘密のトークンを実装します。
コメントで、SSN情報はある時点で入力されるため、実装できる追加の手順の1つは、ユーザーがアプリケーションを再開するときに以前に入力した特に機密性の高い情報を隠すことです。おそらく、進行中のアプリケーションを再開すると、SSNは次のようにのみ表示されます：XXX-XX-1234
最後の4桁だけを表示してSSNを隠すことは完璧な解決策ではないことはわかっていますが、誰かがUUID生成スキームを理解し、有効なURLの束を推測したとしても、完全なSSNのような機密情報を開示したいと思う可能性は非常に高いです。進行中のアプリケーションを継続し、不正に完了するように動機付けられる可能性よりも高くなります。
もう1つの懸念は、これが、確認/検証を実行する機会がある次のステップのために人間によってピックアップされるプロセスのアプリケーションである場合、最後のステップが「銀行口座番号を入力する」である場合とは異なる問題です。私たちのようにお金を預ける」