Laravel Model Shield Laravel Package

Getting Started

ModelShield is an attribute-protection layer for Eloquent models, and ShieldSentry is the adapter that lets you apply it to a Cartalyst Sentry User model without breaking Sentry's own authentication flow.

1. Install and register. Pull the package in via Composer and, if it ships a service provider/config, publish it and review the shielded-attribute defaults before writing any data.
2. Wire the trait into your User model. The documented entry point is subclassing Sentry's Eloquent user rather than editing the vendor model:

use Cartalyst\Sentry\Users\Eloquent\User as SentryModel;
use Vinicius73\ModelShield\Traits\ShieldSentry;

class User extends SentryModel
{
    use ShieldSentry;
}

3. Point Sentry at your model. Ensure your sentry.php config (users.model) resolves to the new App\User, otherwise you'll write shielded records that Sentry never reads back.
4. First use case. Protecting sensitive non-password columns on the user record (secondary emails, API tokens, recovery answers, profile PII) while leaving Sentry in charge of password hashing and login throttling.

Look first at the trait source and any config file — that's where the list of shielded fields and the hashing/encryption strategy is defined.

Implementation Patterns

• Subclass, don't fork. The ShieldSentry pattern composes with Sentry's existing traits. Keep your Sentry model as the base and layer ModelShield on top; don't copy the vendor model into app/.
• Keep concerns separated. Let Sentry own password, persist_code, and reset_password_code. Use ModelShield only for fields Sentry doesn't already transform, so you don't double-hash a credential.
• Migrations first. Add any new shielded columns as nullable text/string wide enough for ciphertext/base64 output — encrypted values are materially longer than plaintext.
• Model-level, transparent access. Read and write shielded attributes as normal Eloquent properties; the trait should handle transform on get/set. This is the day-to-day win: controllers and views stay unchanged.
• Data backfills. When enabling shielding on an existing table, write a one-off command that loads each row and re-saves the affected attributes so the trait re-encodes them. Run against a copy first.
• API serialization audit. If you toArray()/toJson() models to clients, confirm shielded fields are still transformed (or explicitly $hidden) so you don't leak ciphertext or, worse, bypass the transform.
• Testing. Factory-create users through the real model so the trait runs. Assert round-tripping (write → reload → read) rather than inspecting raw column values.

Gotchas and Tips

• Trait ordering and method collisions. ShieldSentry overrides attribute access. If you also use Sentry traits or your own getAttribute/setAttribute overrides, resolve collisions explicitly — call the parent or alias the trait. Silent shadowing is the most likely first bug.
• Encrypted ≠ queryable. Shielding fields breaks where('email', ...), LIKE searches, and unique-index semantics. Keep searchable/login fields (email, username) unshielded or maintain a separate deterministic hash column for lookups.
• Key management. Encryption depends on APP_KEY (or a dedicated key). Rotating keys without a re-encryption pass will make existing shielded values unreadable. Treat key rotation as a migration, not a config change.
• Double-transform risk. Re-saving an already-shielded value can re-encode it if getters return ciphertext in some code paths (e.g. DB::table() queries, raw selects). Always go through the model.
• Version maturity. This is v1.1 — the public surface is young. Pin the version in composer.json and read the changelog before minor bumps; expect config keys and trait names to settle over time.
• Debugging tip. When a value looks wrong, inspect both the raw column (DB::table('users')->...) and the model attribute in tinker — if only the raw value is encoded, the trait is working; if the model value is also encoded, your getter chain is misconfigured.
• Extension point. The config (shielded-field list and transform strategy) is the intended customization lever — prefer adjusting it over overriding trait methods, so upstream updates merge cleanly.