Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.x] Add expires_at functionality to tokens. #252

Merged
merged 2 commits into from Feb 25, 2021
Merged

[3.x] Add expires_at functionality to tokens. #252

merged 2 commits into from Feb 25, 2021

Conversation

bjhijmans
Copy link

Adds an expires_at timestamp to tokens. If the expires_at has passed, the token can no longer be used.

This may allow users to set different expiration times for different tokens. So you can create a token used for a one-time import that expires in automatically in a week, and a token that generates daily reports that doesn't expire.

This also lets developers enforce different expiration times for different tokens based on the type of user, or the privileges of the token.

@driesvints driesvints changed the title Add expires_at functionality to tokens. [3.x] Add expires_at functionality to tokens. Feb 23, 2021
@taylorotwell taylorotwell merged commit 729e2ed into laravel:master Feb 25, 2021
@ankurk91
Copy link
Contributor

It has been 1 year and this feature has not been released.

Any plans for v3?

@driesvints
Copy link
Member

Yeah I have it on my list to look into. Maybe in Q2.

@lindyhopchris
Copy link

Just noting that the Carbon $expires_at = null argument on the createToken method should be type-hinted as CarbonInterface instead, for apps that have set CarbonImmutable as their default date class.

@driesvints
Copy link
Member

@lindyhopchris it was changed to DateTimeInterface in a later commit.

@lindyhopchris
Copy link

@driesvints ah great! sorry, just looked at the PR diff.

@ankurk91
Copy link
Contributor

This date should be considered in Model prune command?

@qschmick
Copy link

Just highlight that this updates an existing migration so applications with this already installed will not add the new field. This should have been a new migration to add the field.

@ankurk91
Copy link
Contributor

There must be an upgrade guide in repo

@tcampbPPU
Copy link

Do I need to manually add the migration to that table myself if I am currently using version: 2.15?

@sfneal
Copy link

sfneal commented Jul 29, 2022

Here's the migration I created to add an 'expires_at' column when upgrading from v2 to v3

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->timestamp('expires_at')->after('last_used_at')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->dropColumn('expires_at');
        });
    }
};

@qschmick
Copy link

qschmick commented Aug 1, 2022

Good one @sfneal just FYI for all that see this, you can't add this migration to a v3 version as that column will already exists and the migration will fail. If you make the following change it could be added without an issue:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        if (! Schema::hasColumn('personal_access_tokens', 'expires_at') {
            Schema::table('personal_access_tokens', function (Blueprint $table) {
                $table->timestamp('expires_at')->after('last_used_at')->nullable();
            });
        }
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->dropColumn('expires_at');
        });
    }
};

@Apfelwurm
Copy link

@qschmick youre migration is nice, but it's currently missing a closing bracket in the if clause.

fixed one:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        if (! Schema::hasColumn('personal_access_tokens', 'expires_at')) {
            Schema::table('personal_access_tokens', function (Blueprint $table) {
                $table->timestamp('expires_at')->after('last_used_at')->nullable();
            });
        }
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->dropColumn('expires_at');
        });
    }
};

@qschmick
Copy link

qschmick commented Aug 2, 2022

Thanks @Apfelwurm great catch

@dan-the-dev
Copy link

Here's the migration I created to add an 'expires_at' column when upgrading from v2 to v3

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->timestamp('expires_at')->after('last_used_at')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('personal_access_tokens', function (Blueprint $table) {
            $table->dropColumn('expires_at');
        });
    }
};

This should be more exposed and suggested as migration step from 2 to 3 in official places.

@qschmick
Copy link

Does appear to be in the upgrade.md

https://github.com/laravel/sanctum/blob/3.x/UPGRADE.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants