本来はこれが望ましいのですが、今回は移行元のチェック方法と違うので変更が必要です。パスワードチェックの重要な変更部分は以上2点です。今回つくった処理まずハッシュ化や比較を行うhasherを自作します。interfaceに沿って実装しましょう。今回重要なmakeとcheckの実装は以下のようにしました。$hashedValue;}これは移行元のロジックをなるべくそのまま持ってきました。(ちなみに実際はOldApplicationHasherなんて名前ではありません汗)hash_hmac()の第一引数の設定値などをどこに持つか悩んだのですが、今回はconfigに以下の通り持たせることにしました。'abcdefghijklmnopqrstuvwxyz',],当然、どちらも移行元と揃えます。これでパスワードのハッシュ値との比較処理は作成できました。次はこれを使うvalidateCredentialsを置き換えます。EloquentUserProviderを継承し、validateCredentialsをオーバーライドしましょう。}}これで、先ほど作成したcheck処理にsaltを渡すことができました。移行元の処理を再現することはできましたが、このままではこれらの処理は使われません。デフォルトの依存解決を変更する必要があります。OldApplicationEloquentUserProviderに渡すHasherを変更するため、ServiceProviderをつくりましょう。}}このServiceProviderを作成したあと、AppServiceProviderで以下のように登録しておきます。true);認証のproviderはデフォルトではEloquentUserProviderですが、Auth::providerで変更ができます。こちらもAppServiceProviderで、以下のように記述しましょう。$config['model']);});このold_application_eloquentというproviderを使うよう、auth.phpを変更します。],これでようやく依存解決で自作のものが注入されるようになります。saltなどの保存saltの保存はどのタイミングで行うか迷ったのですが、今回はパスワードの保存時に同時に行いました。ハッシュ値の生成}詳細は省きますが、このsetPasswordAttributeメソッドはEloquentでpasswordフィールドに値が設定されると呼び出されます。代入していますが、これで保存されると考えてください。まとめ関連するクラスがいくつかあるので、処理の流れを把握して必要なものだけを置き換えるハッシュ化の処理だけ差し替えることができて、Laravelは便利だなぁ今回さらに問題を複雑にしたのは、saltというパスワード以外のカラムの存在と、bcryptと共存しなければならないという要件です。それらがなければ、Hasherクラスのみ自作してhashing.phpのdriver(つまりデフォルト)を変更するのみで良かったのですが・・・。ユーザーデータが存在するアプリケーションの移行時には、こういった選択肢も検討してみてください。余談2019年を振り返ると、2018年よりもさらにプロダクトの成長のことばかり考えていたような気がします。いうポッドキャストを始めたりなどしていました。他には、個人的なライフイベントもありいかに時間を有効に使うかを考えた年でもありました。新しい技術にアンテナを貼る・試すのは日常的にやっていましたが、気になるもの全てに対してやるのは時間が足りません。そのため「プロダクトに貢献するか?」を特に重視した技術選定になりました。Blogスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。