Contrôle des champs#

Toutes les colonnes n'ont pas leur place dans un log d'audit. Les timestamps, les compteurs en cache et les champs sensibles comme les mots de passe doivent être filtrés. AuditChain fournit trois mécanismes pour cela.

Inclure des champs spécifiques#

Utilisez $auditInclude pour n'auditer que les champs listés. Tous les autres sont ignorés :

class User extends Model implements Auditable
{
    use HasAuditTrail;

    protected array $auditInclude = ['name', 'email', 'role'];
}

Lorsqu'un User est mis à jour, seules les modifications de name, email ou role apparaissent dans old_values et new_values.

Exclure des champs spécifiques#

Utilisez $auditExclude pour exclure des champs spécifiques tout en auditant tout le reste :

class User extends Model implements Auditable
{
    use HasAuditTrail;

    protected array $auditExclude = ['last_login_at', 'login_count'];
}

Exclusion automatique des champs masqués#

Les champs listés dans le tableau $hidden du model sont automatiquement exclus des valeurs d'audit. Cela empêche les mots de passe, les tokens API et autres secrets d'être enregistrés :

class User extends Model implements Auditable
{
    use HasAuditTrail;

    protected $hidden = ['password', 'remember_token'];
    // password et remember_token sont automatiquement exclus des logs d'audit
}

Cela s'applique en plus de tout champ $auditExclude. Vous n'avez pas besoin de lister les champs $hidden dans $auditExclude.

Liste de blocage de sécurité#

Indépendamment de la configuration de $auditInclude, $auditExclude ou $hidden, les champs suivants sont toujours exclus des logs d'audit :

• password
• remember_token
• two_factor_secret
• two_factor_recovery_codes

Cette liste de blocage est codée en dur et ne peut pas être surchargée. Elle agit comme un filet de sécurité pour empêcher les données d'authentification sensibles d'apparaître dans le journal d'audit, même si un développeur retire accidentellement ces champs de $hidden ou les ajoute à $auditInclude.

Capture de $hidden au boot#

Les champs $hidden du model sont capturés une seule fois au moment du boot (lors de l'initialisation du trait). Cela signifie qu'appeler $model->makeVisible('password') à l'exécution n'affecte pas les champs exclus des logs d'audit. La liste $hidden originale est immunisée contre les modifications à l'exécution, empêchant l'exposition accidentelle de champs sensibles.

Ordre de priorité#

Les règles sont appliquées dans cet ordre :

1. Si $auditInclude est défini, seuls ces champs sont conservés
2. Les champs dans $auditExclude sont retirés
3. Les champs dans $hidden (capturés au boot) sont retirés
4. Les champs de la liste de blocage de sécurité sont retirés

Si $auditInclude et $auditExclude sont tous deux définis, l'inclusion est appliquée en premier, puis l'exclusion. En pratique, utilisez l'un ou l'autre.

Ce qui est filtré#

Le contrôle des champs s'applique aux colonnes old_values et new_values lors des événements CRUD automatiques. Pour les événements personnalisés où vous fournissez les valeurs manuellement via audit(), les valeurs sont stockées telles quelles — le contrôle des champs ne s'applique pas.

Exemple pratique#

Un model typique avec des préoccupations mixtes :

class Account extends Model implements Auditable
{
    use HasAuditTrail;

    protected $hidden = ['api_secret'];

    protected array $auditExclude = [
        'last_seen_at',
        'notifications_read_at',
    ];
}

Cela audite tous les changements significatifs tout en excluant le secret API (via $hidden) et les champs de timestamps bruyants (via $auditExclude).