[10.x] Model::preventAccessingMissingAttributes() raises exception for enums & primitive castable attributes that were not retrieved

[cosmastech]

Revisiting #49470

In hopes to resolve #49434

Previously, a castable attribute that was not retrieved from the DB would not raise this exception. By checking that the attribute was retrieved before attempting to cast the attribute, the preventAccessingMissingAttributes works intuitively in such a case. We will only raise the exception for primitive castables and enums, as it is possible that other custom casters are "virtual" and do not correspond to DB columns.

[kyryl-bogach]

This commit makes the integration with Laravel Passport to fail (if the preventAccessingMissingAttributes is enabled):

In vendor/laravel/passport/src/Bridge/ClientRepository.php, there's a check on the handlesGrant function that will fire a missing attribute exception because grant_types is not defined in that model. The only thing defined for that property is a cast, which was probably preventing the issue in the first place.

[cosmastech]

This commit makes the integration with Laravel Passport to fail (if the preventAccessingMissingAttributes is enabled):

In vendor/laravel/passport/src/Bridge/ClientRepository.php, there's a check on the handlesGrant function that will fire a missing attribute exception because grant_types is not defined in that model. The only thing defined for that property is a cast, which was probably preventing the issue in the first place.

I've never looked into the Passport library, so forgive my ignorance.

I only see five references to grant_type in all of the Passport repository. I have no idea what the use case for it is.

@taylorotwell could maybe speak more into what the intended purpose is. I'm happy to submit a PR to Passport to fix it, but my initial thought is to just remove it from \Laravel\Passport\Client::$casts and make it a public property on the model instead.

[markuskooche]

I now have the problem that nullable timestamps are no longer loaded.

My user table:

Schema::create('users', function (Blueprint $table): void {
    $table->id();
    $table->uuid()->unique();
    $table->string('name');
    $table->string('username')->unique();
    $table->string('email');
    $table->string('password');
    $table->string('role');
    $table->string('locale');
    $table->timestamp('last_active_at')->nullable();  // <-- nullable timestamp
    $table->rememberToken();
    $table->softDeletes();  // <-- nullable timestamp 'deleted_at'
    $table->timestamps();
});

If I do info('$this->attributes:', $this->attributes):

[2024-01-25 16:09:59] testing.INFO: $this->attributes: {
    "name":"Jessica Schumm",
    "username":"lura98",
    "email":"mark82@example.net",
    "password":"$argon2id$v=19$...7eqnqw",
    "remember_token":null,
    "role":"ADMIN",
    "locale":"en",
    "uuid":"192c1652-0495-4d65-a4c4-e13c9378802c",
    "updated_at":"2024-01-25 16:09:59",
    "created_at":"2024-01-25 16:09:59",
    "id":1
}

BUT the column deleted_at and last_active_at is missing!!

Can someone help me here?

[kyryl-bogach]

Due to this change? @markuskooche

[markuskooche]

@kyryl-bogach I checked it with version 10.39 and the attributes array looks the same, but the values are lazy loadable. This problem happens only when using $request()->user().

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

// INFO: Problem also happens within normal middlewares.
class TerminableMiddleware
{
    /**
     * Handle an incoming request.
     *
     * @param  Closure(Request): (Response)  $next
     */
    public function handle(Request $request, Closure $next): Response
    {
        return $next($request);
    }

    /**
     * Handle tasks after the response has been sent to the browser.
     */
    public function terminate(Request $request, Response $response): void
    {
        // HERE '$request->user()?->last_active_at' IS NOT LOADED
        // Do something..
    }
}

If I do $request->user()?->refresh(), the nullable timestamps are loaded correctly.

[markuskooche]

@kyryl-bogach You can ignore my question. I found the problem, it is related to a different package. :)

[kyryl-bogach]

@markuskooche thanks for the heads-up! I was trying to replicate it with no luck 😁