Fix »OAuth Client Table Changes« migration snippet in the upgrade guide

[hettiger]

The migration code snippet of the v13 upgrade guide immediately crashed on me.
I had to apply several fixes.

Please see commit descriptions for more details.

Using \App\Models\User::class even though old apps might still use \App\User::class does not seem to be that big of an issue. The IDE should immediately highlight the missing class. (eefdb76)

[hafezdivandari]

Passport supports Laravel 11+ but the suggested syntax is available since 12+ AFAIK. Anything wrong with current syntax?

[hettiger]

The $table->after('user_id', function (Blueprint $table) { … }); wrap did not work for me in combination with $table->nullableMorphs('owner');.

Passport supports Laravel 11+ but the suggested syntax is available since 12+ AFAIK.

I didn't check that. If it needs to work on L11 too and the owner_type + owner_id columns should end up right after the user_id column, we'd probably have to manually create the individual columns within the $table->after('user_id', function (Blueprint $table) { … }); wrap.

[hafezdivandari]

The $table->after('user_id', function (Blueprint $table) { … }); wrap did not work for me in combination with $table->nullableMorphs('owner');

Weired, I'll run a test on the framework to make sure!

[hafezdivandari]

It was working fine, but a bug /breaking change has been introduced by laravel/framework#56613

Please keep it as is, I'll send a PR to the framework to fix this.

[hafezdivandari]

Declare default instead, you may apply the same change to redirect_uris column too:

Suggested change

	$table->text('grant_types')->nullable();
	$table->text('grant_types')->default('[]');

[hettiger]

Declare default instead

// \Laravel\Passport\Client::grantTypes

Attribute::make(
    get: fn (?string $value): array => isset($value) ? $this->fromJson($value) : array_keys(array_filter([
        'authorization_code' => ! empty($this->redirect_uris),
        'client_credentials' => $this->confidential() && $this->firstParty(),
        'implicit' => ! empty($this->redirect_uris),
        'password' => $this->password_client,
        'personal_access' => $this->personal_access_client && $this->confidential(),
        'refresh_token' => true,
        'urn:ietf:params:oauth:grant-type:device_code' => true,
    ])),
);

If you default to '[]', isset($value) will evaluate to true for all rows during the migration. Therefore $this->fromJson($value) is being called instead of the array_keys(array_filter([ … ])) code, that actually preserves the data ($this->password_client and $this->personal_access_client) during the migration.

⇒ Your suggested change would drop data instead of preserving it.

you may apply the same change to redirect_uris column too:

redirect_uris does not use an isset check so it works just fine. No need to change anything about redirect_uris.

[hafezdivandari]

You're right, so I guess nullable is fine for both columns?

[hettiger]

// \Laravel\Passport\Client::redirectUris

Attribute::make(
    get: fn (?string $value, array $attributes): array => match (true) {
        ! empty($value) => $this->fromJson($value),
        ! empty($attributes['redirect']) => explode(',', $attributes['redirect']),
        default => [],
    },
);

I tested it with just one redirect URL as well as multiple URLs joined by commas. It always worked just fine. The redirect column was not nullable, so we can expect a value. I don't think we need to change anything about it. However, adding the nullable and removing it later, just as we do with grant_types does not hurt either.

[hafezdivandari]

We should make them both nullable because adding a not null column without default causes error on some DB drivers!

[hettiger]

Thank you for the super quick review @hafezdivandari

[hettiger]

@taylorotwell @hafezdivandari

I think this was not 100% ready. I didn't have the time to answer sooner and now coming back here I see this has already been merged. It's not a big deal — no need to revert. However, maybe @hafezdivandari wants to apply his suggested changes in a follow-up PR. I consider this as done on my end.

Thank you! :-)