その情報を保存する必要がある場合
- リクエスト間で永続的でなければなりません。
- ページに表示してはなりません。
次に、実装して Session を使用するSessionAware
必要があります。
とはいえ、ユーザーのパスワードを保存したり、パスワードをユーザーに関連付けたりする必要があるかどうかはわかりません。
Webアプリケーションでログインページを作成し、そのアクションでのみパスワードを処理し、データベース(またはその他のもの)に対してパスワードを検証し、パスワード自体ではなくセッションに認証IDを保存する必要があります(ユーザーを検証しません)繰り返しますが、セッションが期限切れにならない限り、ユーザーはログイン ページにリダイレクトされます...パスワードをメモリに保持する必要はありません)。
とはいえ、ユーザー認証のベスト プラクティスでは、入力したパスワードをデータベースに保存されているパスワードと比較して検証することは推奨されていません。
パスワードをハッシュするには、一方向ハッシュ アルゴリズム( s 攻撃を防ぐためにソルトを追加するRainbow Table
) を使用し、データベース上のハッシュされたパスワードと照合する必要があります。このようにして、データベース管理者でさえユーザーのパスワードを知ることができず、パスワードを忘れた場合、パスワードは取得されずにリセットされます。
Java での最良の実装の 1 つは、BCryptに基づくjBCryptです。
それが役立つことを願っています...
編集
Web アプリケーションで処理するオブジェクトを概念的に分離する方法として、2 つの異なる Bean を使用できます。すべてのプロパティを含む読み取り用の「フル Bean」と、書き込み可能なプロパティのみを含む書き込み用の「サブセット Bean」です。変化する。
たとえば、ID とパスワードは変更しないでください...データベースから「フル」を読み取り、JSP に書き込み、次に「サブセット」をデータベースに書き込むことができます (ただし、ユーザー登録ではフルを書き込みます)。 ..
わかりやすくするために、フル Bean はDao
データベース フィールドを正確にマッピングするオブジェクトであり、サブセット Bean はPresentation
、Dao オブジェクトから必要な属性のみをコピーして作成するオブジェクトです...どちらも DTO ですが、 2 つの異なるレベルのセマンティックを使用します。
それ以外の場合は、Bean をセッションに入れるだけです。これは 1 行のコードであり、問題ありません。