

いつもお世話になります。

標記の件ですが、下記サイトを参考にコーディングしてみました。

Laravelの認証機能でユーザ情報の論理削除（ソフトデリート）を実装する

・・・が、ソフトデリートしたユーザのメールアドレス、パスワードを  
ログイン画面で入力するとログインできてしまいます。

そもそも論でお聞きしたいのですが、ソフトデリートしたユーザであっても  
ログイン可能なのは仕様なのでしょうか？

ちなみに環境は以下の通りです。

> Laravel 5.5  
>  PHP 7.2.7  
>  MySQL 5.7.22

以上、よろしくお願い致します。

※以下、コーディングした内容です。  
マイグレーションファイルの作成、マイグレートの実行

[code]

    $ php artisan make:migration add_column_softDeletes_users_table --table=users
    
[/code]

> $ view 2018_07_12_045301_add_column_soft_deletes_users_table.php
[code]

    <?php
    
    use Illuminate\Support\Facades\Schema;
    use Illuminate\Database\Schema\Blueprint;
    use Illuminate\Database\Migrations\Migration;
    
    class AddColumnSoftDeletesUsersTable extends Migration
    {
        /**
         * Run the migrations.
         *
         * @return void
         */
        public function up()
        {
            Schema::table('users', function (Blueprint $table) {
                $table->softDeletes();
            });
        }
    
        /**
         * Reverse the migrations.
         *
         * @return void
         */
        public function down()
        {
            Schema::table('users', function (Blueprint $table) {
                $table->dropColumn('deleted_at');
            });
        }
    }
    
[/code]

モデルの作成

[code]

    $ php artisan make:model Models/Users
    
[/code]

> $ view Users.php
[code]

    <?php
    
    namespace App\Models;
    
    use Illuminate\Database\Eloquent\Model;
    use Illuminate\Database\Eloquent\SoftDeletes;
    
    class Users extends Model
    {
        use SoftDeletes;
    
        protected $table = 'users';
        protected $dates = ['deleted_at'];
    }
    
[/code]

下記SQL文にて、ユーザをソフトデリートしました。

[code]

    update users set deleted_at = '2018-07-12 01:03:26' where id = 1;
    
[/code]

前項でソフトデリートしたユーザでログインを試みるとログインできてしまいます。


CC BY-SA 4.0
2018-07-12T07:26:51.437
45552
2018-07-17T11:05:05.853
2018-07-12T08:28:57.950
2238
29282
question
php laravel-5
論理削除（ソフトデリート）したユーザをログイン不可にしたい


そもそも論でいえば、Laravel (Eloquent ORM) の `SoftDeletes` トレイトは、自身が適用された `users`
テーブルが、ユーザ認証に使われているかどうかについて関知しないので、`SoftDeletes`
トレイトを用いて論理削除を設定したテーブルで、認証処理を実現するのは（つまりソフトデリートされたユーザを実際にログイン不可能にするのは）実装者の責任になります。

a. とは言え、例えば

[code]

    $user = App\Models\Users::where(['name' => 'admin', 'password' => 'P@ssw0rd'])->first();
    
[/code]

の様に、`SoftDeletes` トレイトを適用した `Users`
モデルを経由してログイン処理を実装していれば、そのような仕様は自然に実現できると思うので、そのように実装したつもりなら実際の認証処理周りのコードを確認しないと何とも言えません。

b. しかし、もし

[code]

    $user = DB::table('users')->where(['name' => 'admin', 'password' => 'P@ssw0rd'])->first();
    
[/code]

の用なコードでログイン処理を実装していた場合、こちらは `SoftDeletes` トレイトを適用した `Users`
モデルを経由しないので、`deleted_at`
カラムの値に関わらず、論理削除されたレコードも返却されます（本題の仕様的に言えばログイン可能になってしまいます）。

c. もちろん PDO やその他の MySQL ドライバを用いて SQL を発行した場合も同様に（`SoftDeletes`
トレイトが提供する）`deleted_at` カラムを用いた論理削除は考慮されません。

とにかく今一度ログイン認証処理まわりが `Users` モデルを利用して実装されていること、つまり「Eloquent ORM
を通さずにユーザ認証にかかわるクエリを発行していないか」をご確認ください（実際の認証処理まわりのコードの添付も合わせてご検討ください）。


CC BY-SA 4.0
2018-07-17T11:05:05.853
46679
2018-07-17T11:05:05.853
28832
45552
answer