Skip to main content
Browser monitoring est une fonctionnalité en beta d’AppSignal Labs. Le package @appsignal/browser est publié sous le tag beta sur npm, et sa configuration ainsi que son API peuvent encore changer d’une release beta à l’autre. Partagez vos retours dans notre communauté Discord.
La télémétrie front-end est plus proche des données personnelles que la télémétrie back-end. Les URL transportent des tokens, les formulaires des numéros de carte, et le texte d’un bouton peut être un montant de commande. AppSignal pour Browser est prudent par défaut, et toutes les décisions restantes vous appartiennent.

Ce qui est protégé par défaut

Sans aucune configuration :
  • La plupart des champs d’URL créés par le SDK omettent les paramètres de requête par défaut. Cela couvre les URL des pages d’erreur, les URL des pages de web vitals, les breadcrumbs de navigation, et les breadcrumbs fetch/XMLHttpRequest. Le breadcrumb réseau initial du chargement du document fait exception, comme expliqué plus bas.
  • Le SDK ne lit pas les corps de requête ou de réponse des appels réseau. Vérifiez les données que votre propre code place dans les erreurs, la sortie console, les tags ou les breadcrumbs manuels.
  • Aucun cookie n’est lu ni écrit. Le SDK stocke des valeurs appsignal_* dans localStorage et sessionStorage. Celles-ci incluent des identifiants aléatoires pour la session, l’onglet et le visiteur, l’heure d’activité, et les tags que vous avez définis. L’identifiant de visiteur est une valeur aléatoire sans rien de personnel. L’identifiant de visiteur persiste entre les visites. Traitez-le comme un identifiant dans votre politique de confidentialité.
  • Les avertissements et erreurs de la console sont coupés après les 200 premiers caractères. Le SDK ne capture pas console.log.
  • Rien n’est envoyé quand active vaut false. Le SDK ne modifie rien sur la page, ne démarre aucun minuteur et n’émet aucune requête.

URL et paramètres de requête

privacy.queryParamsAllowlist liste les paramètres de requête à conserver dans les champs d’URL ci-dessous. Les autres paramètres de requête sont retirés de ces champs. Vous pouvez utiliser * pour faire correspondre plusieurs noms à la fois : utm_* conserve donc tous les paramètres UTM. La liste par défaut est vide, ce qui les supprime tous. Cela s’applique aux breadcrumbs fetch/XMLHttpRequest et de navigation. Cela s’applique aussi aux erreurs de requête rapportées automatiquement, aux URL des pages d’erreur, aux référents, et aux URL des pages de web vitals.
Avec ce réglage : Les deux dernières lignes forment la paire importante. Les deux URL ont quelque chose après un #, et elles sont traitées différemment à dessein. La troisième URL contient des données au format requête après le #, donc le SDK en retire le token dans ces champs filtrés. La quatrième URL est une route à hash, que le SDK conserve. Cela inclut tout texte de requête à l’intérieur d’une route à hash, comme #/payment?token=abc. Gardez les secrets hors des routes à hash. Les ancres simples comme #pricing sont également conservées.
Le breadcrumb réseau initial du chargement du document utilise actuellement l’URL d’atterrissage complète, même quand queryParamsAllowlist est vide. networkBlocklist ne le filtre pas. Si les URL d’atterrissage peuvent contenir des secrets, écartez ce breadcrumb avec beforeBreadcrumb :

Exclure des requêtes réseau

privacy.networkBlocklist liste les appels fetch et XMLHttpRequest qui ne doivent laisser aucun breadcrumb, et qui ne sont non plus jamais rapportés comme requêtes échouées. La requête a lieu normalement. Seul son enregistrement est ignoré. Les motifs sont comparés à l’hôte et au chemin de l’URL. Un * seul correspond à une partie du chemin, et ** correspond à un nombre quelconque de parties.

Masquer et bloquer des éléments de page

Deux options contrôlent ce qui est enregistré quand un utilisateur sélectionne quelque chose. Les deux options prennent des sélecteurs CSS. Sélectionner un conteneur couvre aussi ses descendants. privacy.dom.maskText remplace le texte d’un élément correspondant par [masked]. Le breadcrumb est tout de même enregistré, vous conservez donc le fait que quelqu’un l’a sélectionné :
Un libellé data-breadcrumb prend le pas sur le masquage de texte. Ne mettez pas de valeurs sensibles dans cet attribut. privacy.dom.blockElement n’enregistre rien du tout. Utilisez-le pour les formulaires de carte bancaire, les numéros d’identité et tout ce qui ne doit jamais apparaître :
Ces deux options n’affectent que ce qui est enregistré quand un utilisateur sélectionne quelque chose. Elles ne touchent ni les messages d’erreur, ni les URL réseau, ni les avertissements et erreurs de la console. Pour cela, utilisez queryParamsAllowlist, networkBlocklist et les deux fonctions de la section suivante.

Filtrer les erreurs et les breadcrumbs

Deux hooks vous permettent de filtrer les erreurs avant qu’elles ne soient rapportées, et les breadcrumbs avant qu’ils n’entrent dans le buffer. Aucun des deux ne peut être async. beforeError s’exécute pour les erreurs qui passent le sampling et la limite de débit globale. Retournez null pour écarter une erreur, ou modifiez ses champs pour en retirer du texte sensible :
Retourner null n’envoie aucune erreur et n’ajoute aucun breadcrumb d’erreur. La limite de débit globale est vérifiée en premier, donc les erreurs écartées comptent tout de même dedans. Une requête échouée arrive ici sous forme d’HTTPError ou de TimeoutError. Ses champs url, method, status et duration_ms se trouvent sous context.request. Si vous y expurgez l’URL, expurgez-la aussi dans le message d’erreur, qui contient l’URL de la requête. beforeBreadcrumb s’exécute une fois pour chaque breadcrumb, au moment de son enregistrement. Retournez null pour le jeter, ou modifiez ses champs message et data :
beforeError ne peut pas voir les breadcrumbs, car ils sont attachés à l’erreur après que cette fonction l’a approuvée. Utilisez plutôt beforeBreadcrumb pour nettoyer le contenu des breadcrumbs.
Aucune de ces deux fonctions ne peut être async. Si beforeError retourne une promesse, AppSignal journalise un console.error et jette l’erreur. Effectuez tout traitement lent avant d’appeler captureError, pas à l’intérieur de ces fonctions.
Rien n’est collecté avant l’exécution d’init() : demander le consentement d’abord consiste donc simplement à ne pas l’appeler avant de l’avoir obtenu.
destroy() arrête la collecte immédiatement, en envoyant ce qu’il avait déjà rassemblé. Cela n’affecte que la page sur laquelle se trouve l’utilisateur. Conservez sa décision vous-même et vérifiez-la avant d’appeler init(), sinon la page suivante qu’il ouvre recommence à collecter.

Ce que vous pouvez dire à vos utilisateurs

Une erreur rapportée peut inclure jusqu’à 25 breadcrumbs récents. Selon ce qui s’est passé avant elle, ceux-ci peuvent décrire :
  • Les pages qu’ils ont ouvertes.
  • Ce qu’ils ont sélectionné, et à quel endroit de l’écran ils l’ont sélectionné. Les libellés de clic peuvent inclure du texte visible, masquez donc les éléments sensibles.
  • Les requêtes émises par la page, et si chacune a réussi.
  • Les avertissements et erreurs que la page a journalisés dans la console.
  • Des tâches longues.
L’erreur inclut aussi tous les tags que vous avez définis. Les lots de web vitals contiennent des valeurs de métriques et du contexte de visite, mais n’incluent pas cette suite de breadcrumbs par défaut. La page des breadcrumbs contient la liste complète. Chaque lot de web vitals transporte aussi du contexte de visite. Cela inclut des identifiants aléatoires pour la session, l’onglet et le visiteur, l’URL de la page et son référent. Cela inclut aussi le user agent, la taille de l’écran et de la fenêtre, la langue et le fuseau horaire. Là où le navigateur les expose, il transporte également le type de connexion et la quantité de mémoire de l’appareil. Le SDK ne lit pas directement les valeurs des champs de formulaire, les corps réseau ou les cookies. Le SDK génère un identifiant de visiteur aléatoire. Il persiste sur l’appareil entre les visites. Vos propres messages d’erreur, tags et breadcrumbs peuvent contenir des détails personnels. Vérifiez-les avant d’envoyer des données à AppSignal.