Au cours des derniers mois, j'ai travaillé dur pour rénover l'expérience de surveillance pour les développeurs Symfony. La bibliothèque de surveillance Symfony est la deuxième bibliothèque la plus populaire parmi les clients d'Inspector. Le premier est le package Laravel.
La sortie de la dernière version du framework a offert l'opportunité de rendre l'expérience de surveillance des applications aussi simple que jamais.
Dans cet article, je détaillerai quels sont ces changements et leur impact sur votre expérience de surveillance dans Inspector.
Pour des articles plus techniques vous pouvez me suivre sur Linkedin ou X.
Compatibilité avec Doctrine 3.x
La dernière version majeure du plus important ORM pour Symfony est sortie au début de cette année. Et il a abandonné la prise en charge des enregistreurs SQL au profit d'une nouvelle « architecture middleware ».
Nous avons implémenté une vérification à l'intérieur du bundle pour vérifier quelle version de Doctrine l'application utilise pour injecter un enregistreur SQL ou un middleware en conséquence.
Collectez le nom de l'itinéraire
La première implémentation de la bibliothèque de surveillance Symfony consistait à utiliser le nom de la route pour surveiller le trafic http par rapport à votre application Symfony :
En gros lorsque vous implémentez une nouvelle route dans Symfony vous pouvez la déclarer via un attribut sur la méthode du Controller :
namespace App\Controller; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Attribute\Route; class HomeController { #[Route('/', name: 'app_homepage')] public function home() { return new Response('Home Page'); } #[Route('/landing', name: 'app_landing')] public function landing() { return new Response('Landing Page'); } }
L'objet Route obtient le nom de la route comme deuxième paramètre, vous pouvez donc référencer cette route dans l'application en utilisant son nom au lieu d'écrire le chemin. Cela vous permet de modifier le modèle d'URL à l'avenir sans avoir besoin de le modifier dans chaque ligne de code mentionnée.
Et si vous souhaitez ignorer l'un d'entre eux dans votre bibliothèque de surveillance, vous deviez lister le nom de la route dans le fichier de configuration yaml de l'Inspector :
inspector: ingestion_key: '%env(INSPECTOR_INGESTION_KEY)%' ignore_routes: - 'app_landing'
Le premier développeur qui m'a aidé à construire la première version de la bibliothèque n'a pas trouvé de moyen de collecter le véritable modèle d'URL, nous avons donc continué cette implémentation pour ne pas bloquer le travail.
Mais utiliser le nom de la route pour surveiller le trafic HTTP présente plusieurs inconvénients.
Le problème avec les noms de routes
Tout d'abord, le nom de l'itinéraire est facultatif. Il n'est évidemment pas nécessaire de mapper les URL avec des noms dans Symfony. De nombreux développeurs n'utilisaient pas de noms, donc comme données de secours, la bibliothèque collectait le chemin ultime comme : /users/12/profile.
Pire encore, quelqu'un utilise des noms uniquement pour une partie de l'application et a vu la liste des transactions dans le tableau de bord avec des formats mixtes, certains points de terminaison surveillés à l'aide du nom de la route et d'autres points de terminaison avec l'URL.
Le deuxième problème était la possibilité d'ignorer l'URL pour désactiver la surveillance dans certaines parties de l'application. Une application Symfony est généralement segmentée à l'aide de modèles d'URL. Les développeurs ont tendance à regrouper tous les points de terminaison d'administration sous l'URL principale comme /admin/[other sub urls] . si vous souhaitez ignorer des parties de votre application à l'aide de caractères génériques, il pourrait être plus facile de référencer des URL en raison de cette association naturelle (/users*). Il est plus difficile de trouver un modèle plus cohérent dans les noms de routes.
De plus, les données de secours collectées au cas où le nom de l'itinéraire n'existerait pas étaient la véritable URL comme /users/12/profile. Ainsi, chaque fois que le point de terminaison était appelé avec un identifiant différent, il générait une nouvelle ligne dans la liste des transactions. Créer trop de bruit dans les données de surveillance.
Collecter le modèle d'itinéraire
Les modèles de route sont différents de l’URL réelle que vos utilisateurs appellent. La plupart des URL que vous avez dans votre application Symfony sont essentiellement paramétrées comme /users/{id}/profile
Il s'agit d'une implémentation typique dans un contrôleur Symfony :
namespace App\Controller; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Attribute\Route; class HomeController { #[Route('/', name: 'app_homepage')] public function home() { return new Response('Home Page'); } #[Route('/landing', name: 'app_landing')] public function landing() { return new Response('Landing Page'); } }
Et c'est ce que nous devons signaler dans la liste des transactions au lieu de la véritable URL. Car même si le changement d'ID, c'est toujours le même code à exécuter.
Ce changement permet également d'ignorer plus facilement non seulement des URL spécifiques, mais également des parties entières de votre application à l'aide du caractère générique dans le fichier de configuration de l'Inspecteur :
inspector: ingestion_key: '%env(INSPECTOR_INGESTION_KEY)%' ignore_routes: - 'app_landing'
Pour des articles plus techniques vous pouvez me suivre sur Linkedin ou X.
Surveillez gratuitement votre application Symfony
Inspector est un outil de surveillance de l'exécution de code spécialement conçu pour les développeurs de logiciels. Vous n'avez pas besoin d'installer quoi que ce soit sur l'infrastructure, installez simplement le package Symfony et vous êtes prêt à partir.
Si vous recherchez une surveillance HTTP, des informations sur les requêtes de base de données et la possibilité de transférer des alertes et des notifications vers votre environnement de messagerie préféré, essayez Inspector gratuitement. Enregistrez votre compte.
Ou apprenez-en plus sur le site : https://inspector.dev
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Les principaux avantages de l'utilisation des sessions de stockage de la base de données incluent la persistance, l'évolutivité et la sécurité. 1. Persistance: Même si le serveur redémarre, les données de session peuvent rester inchangées. 2. Évolutivité: applicable aux systèmes distribués, garantissant que les données de session sont synchronisées entre plusieurs serveurs. 3. Sécurité: La base de données fournit un stockage crypté pour protéger les informations sensibles.

L'implémentation de traitement personnalisé de session dans PHP peut être effectué en implémentant l'interface SessionHandlerInterface. Les étapes spécifiques incluent: 1) la création d'une classe qui implémente SessionHandlerInterface, telles que CustomSessionHandler; 2) réécrire des méthodes dans l'interface (telles que l'ouverture, la fermeture, la lecture, l'écriture, la détruire, GC) pour définir le cycle de vie et la méthode de stockage des données de session; 3) Enregistrez un processeur de session personnalisé dans un script PHP et démarrez la session. Cela permet de stocker des données dans des supports tels que MySQL et Redis pour améliorer les performances, la sécurité et l'évolutivité.

SessionID est un mécanisme utilisé dans les applications Web pour suivre l'état de la session utilisateur. 1. Il s'agit d'une chaîne générée aléatoire utilisée pour maintenir les informations d'identité de l'utilisateur lors de plusieurs interactions entre l'utilisateur et le serveur. 2. Le serveur génère et l'envoie au client via des cookies ou des paramètres d'URL pour aider à identifier et à associer ces demandes dans plusieurs demandes de l'utilisateur. 3. La génération utilise généralement des algorithmes aléatoires pour assurer l'unicité et l'imprévisibilité. 4. Dans le développement réel, les bases de données en mémoire telles que Redis peuvent être utilisées pour stocker les données de session pour améliorer les performances et la sécurité.

La gestion des séances dans des environnements sans état tels que les API peut être réalisée en utilisant JWT ou des cookies. 1. JWT convient à l'état sans état et à l'évolutivité, mais il est de grande taille en ce qui concerne les mégadonnées. 2.La cookies est plus traditionnel et facile à mettre en œuvre, mais ils doivent être configurés avec prudence pour assurer la sécurité.

Pour protéger l'application des attaques XSS liées à la session, les mesures suivantes sont nécessaires: 1. Définissez les drapeaux httponly et sécurisés pour protéger les cookies de session. 2. Codes d'exportation pour toutes les entrées utilisateur. 3. Implémentez la politique de sécurité du contenu (CSP) pour limiter les sources de script. Grâce à ces politiques, les attaques XSS liées à la session peuvent être protégées efficacement et les données utilisateur peuvent être assurées.

Les méthodes pour optimiser les performances de la session PHP incluent: 1. Delay Session Start, 2. Utilisez la base de données pour stocker les sessions, 3. Compress Session Data, 4. Gérer le cycle de vie de la session et 5. Implémenter le partage de session. Ces stratégies peuvent améliorer considérablement l'efficacité des applications dans des environnements de concurrence élevés.

Thesesse.gc_maxlifetimesettingInphpdeterminesthelifespanofessiondata, setInSeconds.1) it'sconfiguredInphp.Iniorviaini_set (). 2)

Dans PHP, vous pouvez utiliser la fonction session_name () pour configurer le nom de session. Les étapes spécifiques sont les suivantes: 1. Utilisez la fonction session_name () pour définir le nom de session, tel que session_name ("my_session"). 2. Après la définition du nom de la session, appelez session_start () pour démarrer la session. La configuration des noms de session peut éviter les conflits de données de session entre plusieurs applications et améliorer la sécurité, mais faire attention à l'unicité, à la sécurité, à la longueur et à la définition du calendrier des noms de session.


Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
Échangez les visages dans n'importe quelle vidéo sans effort grâce à notre outil d'échange de visage AI entièrement gratuit !

Article chaud

Outils chauds

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

SublimeText3 version anglaise
Recommandé : version Win, prend en charge les invites de code !

SublimeText3 Linux nouvelle version
Dernière version de SublimeText3 Linux

Version Mac de WebStorm
Outils de développement JavaScript utiles

mPDF
mPDF est une bibliothèque PHP qui peut générer des fichiers PDF à partir de HTML encodé en UTF-8. L'auteur original, Ian Back, a écrit mPDF pour générer des fichiers PDF « à la volée » depuis son site Web et gérer différentes langues. Il est plus lent et produit des fichiers plus volumineux lors de l'utilisation de polices Unicode que les scripts originaux comme HTML2FPDF, mais prend en charge les styles CSS, etc. et présente de nombreuses améliorations. Prend en charge presque toutes les langues, y compris RTL (arabe et hébreu) et CJK (chinois, japonais et coréen). Prend en charge les éléments imbriqués au niveau du bloc (tels que P, DIV),