Filament Keyable Laravel Package

Getting Started

filament-keyable is a Filament plugin for attaching and managing API keys against Eloquent models from inside a panel. The 1.2.0 release is purely additive — 16 new locales — so nothing in your setup changes, but the plugin is now realistically usable on non-English admin panels.

Minimal path:

1. composer require jeffersongoncalves/filament-keyable (1.2.0 requires no Laravel/Filament version bumps beyond what 1.1.1 already needed — check composer.json constraints before upgrading a pinned Filament major).
2. Publish and run migrations if the plugin ships a api_keys-style table: php artisan vendor:publish --tag="filament-keyable-migrations" then php artisan migrate. Confirm the exact tag in the README — this package's publish tags follow the vendor-namespace convention.
3. Register the plugin on the panel you want the UI in:

   ->plugin(\JeffersonGoncalves\FilamentKeyable\KeyablePlugin::make())
   

4. Add the package's keyable trait (and interface, if provided) to the model that should own keys, then expose the relation.
5. First use case: stop rotating credentials in Tinker. Open the generated resource, issue a key for a tenant/user/service model, copy the plaintext once, and let support staff revoke it from the table without a deploy.

Where to look first: the resource class (to see which actions — create/revoke/regenerate — are wired up out of the box), then the trait, then resources/lang/. The policy/gate story is the thing that most affects whether you can ship it, so read that before writing UI.

Implementation Patterns

Per-panel registration. Register the plugin only on the panel where key management belongs (a staff/admin panel), not on a customer-facing panel, unless you deliberately want self-service key issuance. If you do want self-service, scope the resource query to auth()->user() in a getEloquentQuery() override rather than relying on the plugin default.

Trait on the owner model. The typical shape is Model::apiKeys() returning HasMany. Keep the trait on domain models (Tenant, Service, User) and not on the key model itself. Wrap key-authenticated routes in your own middleware that resolves the presented key, hashes it, and compares — the plugin gives you the management surface, not the request-time guard.

Multi-tenant panels. If you run Filament's tenancy, add tenant_id (or your ownership column) to the published migration and override the resource's form to prefill it from Filament::getTenant(). Without this the resource will happily list all keys across tenants.

Resource extension over forking. Add columns/actions via the resource's static configuration hooks, or subclass the resource and swap it in the plugin's ->resource() argument if one is exposed. Prefer this to editing vendor files — you'll want clean upgrades when the next locale batch lands.

Localization. After 1.2.0, set app.locale to any of ar, az, de, fa, fr, hi, it, ja, nl, pl, pt, ru, tr, uk, uz, zh_CN and the resource labels follow. To customise wording, publish translations (php artisan vendor:publish --tag="filament-keyable-translations") and edit lang/vendor/filament-keyable/{locale}/... — this survives upgrades, unlike editing the package directory.

Testing. Use livewire()/Filament::test() helpers with RefreshDatabase. Assert two things separately: that the key row is created, and that the plaintext is only returned in the create-response and never retrievable afterwards. That second assertion is the regression test that matters.

Gotchas and Tips

• zh_CN uses an underscore. Laravel has historically accepted both zh_CN and zh-CN in different code paths, but Filament and some tooling normalise to hyphens. If Chinese labels fall back to English, check config('app.locale') and your app.fallback_locale spelling before assuming the translation file is broken.
• RTL locales. ar and fa are in this release. Filament renders LTR by default; confirm your panel's direction handling, otherwise the translated strings will render with mismatched alignment and icon positions.
• Verify coverage, not just file presence. A locale shipping with 16 files doesn't mean every key is translated — expect English fallback for newly added UI strings. Spot-check by switching app.locale and loading the resource.
• Publish before migrate. The most common install failure: registering the plugin and hitting the resource before publishing the migration, which surfaces as a "table not found" from the resource's query rather than an obvious plugin error.
• Plaintext-once. Whatever the resource does, ensure the raw key is not stored in plaintext and is not re-displayable from the table view. If the package shows it in a modal on create, that's fine; if it can be re-read later, override the column.
• Revocation semantics. "Delete" and "revoke" are different. Decide whether revoked keys stay in the table (with revoked_at) for audit — if so, you'll need a soft-delete/status column and a filtered table, since the stock resource likely deletes.
• Config caching. After publishing config, php artisan config:clear in dev and config:cache in deploy. A stale cached config pointing at a namespace that no longer matches is a silent failure mode.
• Upgrade from 1.1.1. No breaking changes claimed, but this release also carries a dependabot group bump and the Renovate config removal. Run composer update --dry-run and read the lock diff before merging; a transitive Filament bump is the realistic upgrade risk, not the translations.
• Extension point worth knowing. The plugin's translation namespace (filament-keyable) is your override lever for terminology — e.g. renaming "Token" to "Client Secret" across the UI via translations rather than subclassing the resource.