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.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_*danslocalStorageetsessionStorage. 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
activevautfalse. 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.
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.
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é :
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 :
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 êtreasync.
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 :
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.
Consentement au suivi
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.