zilyass.
Tous les projets

02 / JOURNALISATION & SÉCURITÉ WEB

Zilyass
Guard.

Garder une trace lisible des événements de connexion, sans enregistrer l’identité des utilisateurs dans le journal.

Technologies
WordPress · PHP · SQL / InnoDB · CSS
Format
Plugin personnel · Prototype
Fonction
Observation & alertes facultatives

DU SIGNAL À LA CONSULTATION

  1. 01 / WORDPRESS

    Un événement

    Un hook signale une connexion réussie ou un échec.

  2. 02 / PHP

    Un enregistrement

    Un identifiant, une date UTC, un type et un résultat.

  3. 03 / SQL

    Un journal

    Une insertion et un nettoyage dans une transaction.

  4. 04 / ADMINISTRATION

    Une lecture

    Des filtres, des compteurs, un export et des alertes optionnelles.

LE POINT DE DÉPARTVoir ce qui
se passe.

Administrer un site demande de comprendre ses événements techniques. Zilyass Guard se concentre sur un besoin précis : consulter certains événements de connexion WordPress dans un journal simple et exportable.

Le plugin s’appuie sur les hooks natifs wp_login et wp_login_failed. Il ne modifie pas la procédure d’authentification et ne demande pas les arguments contenant les identifiants de l’utilisateur.

Guard est un outil d’observation. Il ne bloque pas les attaques, ne scanne pas les fichiers et ne remplace pas une solution de protection. Un échec de connexion peut simplement être une erreur de saisie.

LES FONCTIONNALITÉSUn périmètre
volontairement limité.

  • Journal minimal. Quatre champs : identifiant de l’événement, date UTC, type login et résultat success ou failure.
  • Consultation. Filtrer par résultat et dates, lire les compteurs, parcourir les résultats par pages de 25 événements.
  • Export CSV. Exporter tous les événements correspondant aux filtres, pas seulement les lignes visibles à l’écran.
  • Alertes facultatives. Demander un e-mail après un échec enregistré, au maximum une tentative toutes les dix minutes pour le site.
  • Conservation bornée. Une durée de 30 jours et un plafond de 10 000 événements, appliqués lors des nettoyages.

CHOIX TECHNIQUESUn petit journal,
de vraies contraintes.

Contrôler l’accès

La capacité WordPress manage_options est vérifiée côté serveur. Masquer un bouton ne suffit pas à protéger l’export.

Protéger les actions

Un nonce complète l’autorisation pour l’export et les réglages. Il ne remplace ni l’authentification ni le contrôle des droits.

Garder la cohérence

Une transaction SQL lie insertion et nettoyage. Un verrou coordonne les écritures simultanées du plugin.

Limiter les données

Aucun nom d’utilisateur, mot de passe, cookie ou IP dans les quatre colonnes. L’adresse des alertes est un réglage séparé.

event_id      → identifiant unique de l’événement
occurred_at   → date et heure en UTC
event_type    → login
outcome       → success | failure

Les filtres sont validés, les requêtes SQL utilisent des paramètres préparés et les valeurs affichées sont échappées. L’identifiant unique sert à reconnaître un enregistrement : il ne rend pas le journal inviolable.

ALERTES & CONSERVATIONCe que signifie
un résultat.

Les alertes sont désactivées par défaut. Après configuration, le plugin utilise le transport e-mail de WordPress. Une demande d’envoi acceptée ne prouve pas la réception du message : celle-ci doit être vérifiée séparément.

Les échecs suivants restent enregistrés pendant le délai de dix minutes, mais ne produisent pas une file d’e-mails à envoyer plus tard. Le bouton de test est limité séparément, à un essai par minute.

Le nettoyage intervient lors d’enregistrements, de consultations, d’exports et via une tâche horaire WordPress. Sur un site inactif, la purge physique peut être retardée : la planification WordPress dépend de ses déclenchements.

VÉRIFICATION & LIMITESObserver n’est
pas tout couvrir.

Les tests locaux documentés couvrent notamment l’enregistrement, les filtres, l’export, les droits, la conservation, la concurrence et les alertes. Le transport e-mail y est intercepté pour vérifier les demandes sans envoyer de messages réels.

Le formulaire natif et les connexions utilisant les hooks étudiés constituent le périmètre vérifié. Certains cas, comme des champs vides, peuvent ne pas produire d’événement. Les autres mécanismes d’authentification et extensions tierces n’ont pas une couverture garantie.

Le propriétaire de la base peut modifier les enregistrements. Une panne d’écriture peut faire perdre un événement. Ce prototype n’est donc ni un journal inaltérable ni une garantie de disponibilité sous forte charge.

QUESTIONS DE CONCEPTIONPourquoi
ces choix ?

Pourquoi utiliser les hooks WordPress ?

Ils permettent de réagir à des événements natifs sans réécrire le système de connexion. Le plugin reste indépendant du formulaire et se limite aux signaux qu’il reçoit effectivement.

Pourquoi ne pas enregistrer l’utilisateur ou son IP ?

L’objectif de ce prototype est de compter et consulter des événements, pas d’identifier les personnes. Quatre champs suffisent à cet objectif, avec la limite assumée de ne pas attribuer les échecs à un compte.

Pourquoi une transaction pour l’insertion et la purge ?

Pour que ces opérations restent cohérentes : si une étape échoue, leur annulation évite une application partielle. Le verrou répond à une autre question, celle de plusieurs écritures exécutées en même temps.

En quoi est-ce différent d’un pare-feu ?

Un pare-feu peut filtrer ou bloquer un trafic selon des règles. Guard reçoit certains événements, les journalise et peut demander une notification. Il ne prend pas de décision de blocage.

L’AUTRE PROJET

Zilyass Analytics
Retour au portfolio