- How do I install Filament Sanctum in a Laravel 13 + Filament 5 project?
- Run `composer require devtical/filament-sanctum`, then publish the config and translations with `php artisan vendor:publish --tag=filament-sanctum-config` and `php artisan vendor:publish --tag=filament-sanctum-translations`. The package auto-detects Filament 5 and Laravel 13, so no additional setup is needed for basic functionality.
- Does this package support custom Sanctum token models (e.g., extended with extra fields)?
- No, the package assumes the default `personal_access_tokens` table. If you’ve extended Sanctum’s token model, you’ll need to override the package’s `createToken` method or manually adjust the migration to include your custom fields. Test thoroughly in a staging environment.
- Can I enforce token expiration for all users, or is it optional?
- Token expiration is configurable via the `default_expiration_days` setting in the published config. Set it to `null` to disable expiration entirely, or define custom rules by extending the `PersonalAccessToken` model or overriding the package’s token creation logic.
- What Laravel gates are required to access the Sanctum panel in Filament?
- The package introduces a `viewSanctumPanel` gate by default, which you can configure in the `config/filament-sanctum.php` file. Use `php artisan gate:list` to verify existing gates, and adjust the package’s `authorization` config to match your RBAC system. Fallback to Filament’s `canAccess` middleware during testing if gates are misconfigured.
- Will this work with multi-tenancy (e.g., Stancl/Tenancy or custom)?
- The package respects Sanctum’s default token resolution, but multi-tenancy requires explicit handling. Override `Sanctum::resolveToken()` in your `AuthServiceProvider` to scope tokens to the current tenant. For expiration logic, ensure the `expires_at` column is indexed per tenant if using shared databases.
- How do I audit token revocations or expirations in Filament?
- The package doesn’t include built-in audit logging, but you can integrate with Filament’s native audit logs or Laravel Telescope. Add a `revooked_at` timestamp to the `personal_access_tokens` table and log changes via model observers or Filament’s `LogActivity` trait.
- What if I’m still using Filament 4? Can I downgrade or use a fork?
- Filament 4 support was deprecated in v2.0. You can either stay on `devtical/filament-sanctum v1.0.x` or migrate to Filament 5 (recommended). Forking the package to revert Filament 5 changes is possible but unsupported—assess the effort vs. upgrading, as Filament 5 introduces breaking changes like `MenuItem` → `Action`.
- Are there performance concerns with token expiration queries on large-scale deployments?
- The package adds an `expires_at` column to the `personal_access_tokens` table, which should be indexed for performance. Run `php artisan migrate` to apply the migration, and ensure your database is optimized. For high-traffic apps, consider partitioning the table by `created_at` or `expires_at`.
- How do I customize the token details modal (e.g., add usage history or custom fields)?
- Extend the package’s `TokenDetailsModal` class by publishing the views with `php artisan vendor:publish --tag=filament-sanctum-views` and overriding the blade templates. For dynamic data (e.g., API usage logs), fetch it via the `TokenResource` or add a custom query to the `PersonalAccessToken` model.
- What alternatives exist for managing Sanctum tokens in Filament?
- Alternatives include building a custom Filament resource for Sanctum’s `HasApiTokens` trait or using packages like `spatie/laravel-permission` (if you need role-based token restrictions). However, `devtical/filament-sanctum` is the most feature-complete solution with built-in expiration, RBAC, and a polished UI. Compare by testing each in your stack.