Journal
Le module «Journal» dans Platform OneEntry permet aux administrateurs de suivre à la fois les actions des autres administrateurs dans le système et l'activité de l'API de contenu public. Le module se compose de quatre onglets :
| Onglet | Ce qu'il montre |
|---|---|
| Journal des actions administratives | Toutes les actions des administrateurs dans le système : création, modification, suppression d'entités. |
| Trafic des administrateurs | Sessions de connexion des administrateurs : quand ils se sont connectés, quand ils se sont déconnectés, depuis quel appareil. |
| Statistiques de l'API de contenu | Compteurs d'appels de tous les points de terminaison publics du site sur différentes périodes. |
| Erreurs de l'API de contenu | Tous les réponses 4xx/5xx de l'API publique avec les détails de la requête et la trace de la pile. |
Dans l'interface du module, les onglets sont étiquetés comme suit : Journal Admin, Journal d'accès à l'application Admin, Statistiques de l'API de contenu, Erreurs de l'API de contenu.
Chaque onglet est accessible sous une autorisation distincte — voir Autorisations pour le journal.
Journal des actions administratives
L'onglet principal, montrant toutes les actions des administrateurs dans le système. Auparavant, il s'appelait simplement « Journal des actions administratives » — il a maintenant été renommé en « Journal des actions administratives » pour le distinguer des nouveaux onglets.
Éléments de l'interface
L'onglet se compose de deux blocs :
- Filtres
- Liste des actions
Filtres
Pour filtrer les actions, les champs suivants sont disponibles :
- De — champ de texte pour la date à partir de laquelle il faut filtrer les actions.
- À — champ de texte pour la date jusqu'à laquelle il faut filtrer les actions.
Les dates peuvent être saisies sous forme de chaîne dans le format de date de votre région, ou vous pouvez sélectionner la date souhaitée à l'aide du calendrier qui apparaît lorsque vous cliquez sur le champ de saisie de date.
- ID Administrateur — champ numérique pour l'identifiant unique de l'administrateur.
- Actions utilisateur — liste déroulante des actions de l'utilisateur :
- Création
- Modification
- Suppression
- Statut — liste déroulante des statuts des actions :
- Réussi
- Erreur
- Nom du module — liste déroulante des noms de modules :
- Administrateurs
- Ensembles d'attributs
- Sauvegarde
- Gestion des blocs
- Gestion des événements
- Paramètres généraux
- Téléchargement de fichiers
- Éditeur de fichiers
- Gestion des formulaires
- Localisation
- Marqueurs
- Menu
- Modules
- Gestion de contenu
- Produits
- Gestion des commandes
- Paramètres de base
- Gestion des paiements
- Gestion des statuts de produits
- UTILISATEUR
- Gestion des fournisseurs d'authentification et des utilisateurs
- Gestion des modèles
- Gestion des modèles d'aperçu
- ID d'enregistrement — champ numérique pour l'identifiant unique de l'enregistrement.
Sous le bloc de filtres, deux boutons sont situés :
- Supprimer les données — supprime les enregistrements du journal des actions administratives pour la période spécifiée par les champs De / À (voir Nettoyage des journaux manuellement).
- Réinitialiser — réinitialise les filtres appliqués.
Liste des actions
La liste des actions est présentée sous forme de tableau de six colonnes :
- Actions utilisateur
- Statut
- Connexion utilisateur
- Nom du module
- ID d'enregistrement
- Date et heure
Pour chaque colonne, il est possible de trier les données en cliquant sur l'en-tête de la colonne. La première pression triera par ordre décroissant, la seconde par ordre croissant, la troisième réinitialisera le tri.
Audit de la visibilité du bloc
Chaque changement de visibilité du bloc (toggle « afficher/ne pas afficher » dans l'admin des blocs) est automatiquement enregistré dans le Journal des actions administratives. Il est possible de voir quel administrateur a changé l'état d'un bloc spécifique et quand.
Le changement de visibilité du bloc n'était pas enregistré dans le journal — il était impossible de savoir qui et quand a caché/affiché le bloc. Maintenant, c'est le cas, et l'opération est affichée dans la liste générale avec le type « Gestion des blocs ».
Trafic des administrateurs (Journal d'accès Admin)
L'onglet « Trafic des administrateurs » montre chaque connexion et déconnexion d'un administrateur dans le système comme un enregistrement distinct. Il est maintenant possible de voir immédiatement qui s'est connecté et quand dans l'admin — sans avoir à se référer à Grafana/Loki. Utile pour l'audit (surtout pour les grandes équipes avec plusieurs administrateurs).
Champs du tableau
Le tableau se compose de six colonnes :
| Colonne | Signification |
|---|---|
| Connexion | identifiant de l'administrateur |
| IP | adresse IP depuis laquelle l'administrateur s'est connecté |
| Heure de connexion | date et heure de la connexion |
| Heure de déconnexion | date et heure de la déconnexion (pour une session encore ouverte — vide) |
| Durée | durée de la session (pour une session active — de la connexion jusqu'à maintenant) |
| Raison | raison de la fermeture de la session : logout (l'utilisateur a cliqué sur « Déconnexion ») ou admin_revoked (un autre administrateur a forcé la fermeture de la session, par exemple via logoutAll) |
Comme dans le Journal des actions administratives, n'importe quelle colonne peut être triée en cliquant sur son en-tête.
L'expiration du token (expired) et la ré-authentification (refresh) ne sont pas écrites comme un enregistrement distinct — une telle session est simplement marquée comme fermée paresseusement, lorsque son utilisation cesse effectivement.
Filtres
- De / à — période (champs de saisie de date avec calendrier).
- ID Administrateur — champ numérique pour filtrer par administrateur spécifique.
- Statut de la session — liste déroulante des statuts de session : Tous / Actif / Fermé.
Bouton « Supprimer les données »
Supprime les enregistrements de sessions pour la période spécifiée par les champs De / À. Lors de la pression, une boîte de dialogue de confirmation s'ouvre :
Confirmer l'action — Supprimer toutes les sessions fermées pour la période spécifiée ? Cette action est irréversible. Les sessions actives resteront.
Seules les sessions fermées sont supprimées. Les sessions actives (avec une autorisation ouverte) ne sont pas touchées — c'est une protection contre la suppression accidentelle des collègues en cours de travail.
Statistiques de l'API de contenu
L'onglet « Statistiques de l'API de contenu » montre les compteurs d'appels de tous les points de terminaison publics du site (API storefront) sur différentes périodes — 1 heure, 24 heures, 7 jours.
Ce qu'il montre
- Liste de tous les points de terminaison publics (
GET /api/content/...) — se construit automatiquement à partir du code, rien à maintenir manuellement. - Compteur à côté de chaque point de terminaison — combien de fois il a été appelé pendant la période choisie.
- Les chiffres proviennent de la métrique Prometheus centralisée de nginx-ingress, responsable de notre trafic. Aucun compteur distinct n'est créé dans la base de données du projet.
Éléments de l'interface
- Période — liste déroulante de la période : Dernière heure / Dernières 24 heures / Derniers 7 jours (par défaut — Dernières 24 heures).
- Rafraîchir — bouton pour forcer la mise à jour des données.
Les données sont présentées sous forme de tableau de quatre colonnes :
| Colonne | Signification |
|---|---|
| Chemin | chemin du point de terminaison (/api/content/...) |
| Méthode | méthode HTTP (GET, POST, …) |
| Description | brève description du point de terminaison |
| Requêtes | nombre d'appels pendant la période choisie |
En haut de la page, une bannière d'information est affichée :
Nettoyage automatique non applicable — Les données sont lues en temps réel depuis Prometheus, la rétention est configurée au niveau de l'infrastructure de surveillance. Cet onglet ne stocke pas de données dans la base de données CMS.
Si Prometheus est indisponible, un avertissement « Métrique temporairement indisponible. Tous les points de terminaison sont affichés avec un compteur zéro. » apparaît au-dessus du tableau — la liste des points de terminaison est tout de même affichée, mais avec un compteur de 0.
Les données sont stockées dans Prometheus avec une rétention au niveau de l'infrastructure (généralement 30 jours). Pour une analyse plus longue, il faut stocker soi-même. La bannière d'information en haut de la page avertit à ce sujet.
Pourquoi c'est nécessaire
Le marketing et le produit peuvent voir quelles fonctionnalités de l'API storefront sont réellement utilisées et lesquelles sont mortes. Il est également pratique de surveiller si « tout fonctionne » — une chute brutale des appels d'un point de terminaison indique généralement un problème du côté du front.
La réponse est mise en cache pendant 60 secondes dans Redis — pour ne pas interroger Prometheus à chaque pression sur « Rafraîchir ».
Erreurs de l'API de contenu
L'onglet « Erreurs de l'API de contenu » montre toutes les réponses 4xx/5xx que l'API publique a renvoyées pendant la période. Les développeurs qui intègrent l'application cliente avec notre API n'ont plus besoin d'accéder aux journaux du serveur — toutes les erreurs de leurs requêtes sont visibles directement dans l'admin.
Ce qu'il montre
Chaque enregistrement est une erreur HTTP distincte. Le tableau se compose de cinq colonnes :
| Colonne | Signification |
|---|---|
| Temps | horodatage de l'erreur |
| Statut | statut HTTP (4xx / 5xx) |
| Méthode | méthode de la requête (GET, POST, …) |
| Chemin | chemin (/api/content/...) |
| Message | texte de l'erreur |
Si aucune erreur n'a été enregistrée pendant la période choisie, un message « Aucune erreur enregistrée pour la période sélectionnée » est affiché à la place du tableau.
Le champ « Plus de détails » ouvre un écran détaillé avec :
- Corps de la requête (sans secrets — mots de passe, tokens, en-têtes d'autorisation masqués)
- Query — paramètres de la chaîne de requête
- En-têtes
- Trace de la pile — développée (jusqu'à 8 Ko)
Filtres
- De / à — période (champs de saisie de date avec calendrier).
- Statut HTTP — liste déroulante des statuts. Vous pouvez choisir un groupe (4xx - Côté client, 5xx - Côté serveur) ou un code spécifique : 400, 401, 403, 404, 422, 500, 502, 503.
- Chemin — champ de texte pour filtrer par chemin (par exemple,
/api/content/blocks/*).
Bouton « Supprimer les données »
Supprime les enregistrements d'erreurs pour la période spécifiée par les champs De / À. Si la période n'est pas spécifiée — toutes les erreurs sont supprimées.
Sécurité — Sanitize
Le sanitizeur supprime automatiquement les données sensibles. Les champs password, token, authorization, api_key, x-app-token, cookie, set-cookie (insensible à la casse) sont remplacés par ***. Les grands corps sont coupés à 2 Ko.
Architecture
Les erreurs sont écrites via une file d'attente légère Bull, afin que l'enregistrement dans le journal ne ralentisse pas le traitement de la requête. Si la file d'attente est pleine (plus de 1000 tâches en attente) — de nouvelles erreurs sont silencieusement rejetées, afin de ne pas « planter » Redis.
Nettoyage des journaux manuellement
Les enregistrements du journal sont nettoyés manuellement — sur chaque onglet qui stocke des données dans la base de données, il y a un bouton « Supprimer les données » :
| Onglet | Ce qu'il supprime |
|---|---|
| Journal des actions administratives | enregistrements des actions administratives pour la période choisie |
| Trafic des administrateurs | seulement les fermées sessions pour la période choisie |
| Erreurs de l'API de contenu | enregistrements d'erreurs pour la période choisie |
La période de suppression est définie par les champs De / À dans les filtres de l'onglet. Si la période n'est pas spécifiée — toutes les enregistrements du type correspondant sont supprimés. Avant la suppression, une boîte de dialogue de confirmation « Confirmer l'action » est toujours affichée, l'opération est irréversible.
Le bouton « Supprimer les données » sur l'onglet « Trafic des administrateurs » ne supprime pas les sessions actives des administrateurs — même si une période est spécifiée, couvrant le moment actuel, la session ouverte d'un collègue en cours de travail ne sera pas supprimée. Seules les sessions fermées sont supprimées.
Les données statistiques sont lues en temps réel depuis Prometheus et ne sont pas stockées dans la base de données CMS, c'est pourquoi il n'y a pas de bouton « Supprimer les données » sur cet onglet — cela est signalé par la bannière « Nettoyage automatique non applicable ».
Autorisations pour le journal
Chaque onglet du journal est accessible sous une autorisation distincte dans l'arbre des droits :
| Onglet | Permission |
|---|---|
| Journal des actions administratives | journal.viewAdminActions (droit existant, sans modifications) |
| Trafic des administrateurs | journal.viewAdminAccess (nouveau droit) |
| Statistiques de l'API de contenu | journal.viewContentApiStats (nouveau droit) |
| Erreurs de l'API de contenu | journal.viewContentApiErrors (nouveau droit) |
Lors de la mise à jour du système, les deux nouveaux droits (journal.viewContentApiStats, journal.viewContentApiErrors) sont automatiquement attribués à tous les administrateurs existants ayant le droit admins.get — via une migration de seed. Pour les rôles actuels, rien n'a été cassé.