Comment créer des appareils et des cibles

WebSocket est un protocole de communication qui fonctionne sur TCP et est conçu pour échanger des messages entre un navigateur et un serveur Web en temps réel. Le navigateur (client) et le serveur utilisent un protocole similaire à HTTP pour établir une connexion WebSocket.

Pour plus d’informations sur le protocole WebSocket et la surveillance des applications WebSocket, veuillez visiter le blog Dotcom-Monitor.

Un périphérique WebSocket créé dans la plate-forme Dotcom-Monitor vérifie la disponibilité, les performances, le contenu approprié et les erreurs d’une seule URL WebSocket. Le dispositif de surveillance peut également être configuré pour valider les certificats de sécurité et le contenu de réponse.

Configuration d’une demande

Url

Pour ouvrir une connexion WebSocket, vous devez saisir l’URL WebSocket du point de terminaison ou de l’adresse IP de l’URL WebSocket que vous souhaitez vérifier (les protocoles ws:// et wss:// cryptés sont pris en charge). Par exemple, wss://echo.websocket.org/

Pour activer un mode d’entrée plus convivial visuellement, cliquez sur l’interrupteur détaillé en haut de la section.

Vous pouvez convertir l’URL en une valeur dynamique ou un paramètre de contexte ici. Par exemple, vous pouvez modifier dynamiquement l’URL cible lors de la surveillance.

Envoyer des données

Une fois la connexion ouverte, Dotcom-Monitor écoute les événements dans la prise. Si vous devez transférer des données vers le point de terminaison cible, dans le champ Envoyer des données, spécifiez un message dans une chaîne ou un format binaire. Dotcom-Monitor enverra le message au point de terminaison cible à l’aide du protocole WebSocket et attendra la réponse.

Dotcom-Monitor prend en charge les expressions Razor dans les messages WebSocket. Pour envoyer une chaîne contenant une expression Razor, entrez-la dans le champ Envoyer des données et utilisez le script Préparer pour définir le type de message à l’expression Razor. Sinon, le message sera analysé et envoyé sous forme de texte. Utilisez l’extrait de code suivant dans le champ Préparer le script pour informer le système qu’il doit analyser le message avec le moteur Razor :

ProcessPostDataByRazor(currentTask);

En plus du moteur Razor, Dotcom-Monitor permet de modifier dynamiquement les données du corps de demande à l’aide de masques de données. Pour savoir comment utiliser la syntaxe Razor et les masques de données dans les données envoyées, et configurer la charge utile en évolution dynamique, voir Comment modifier dynamiquement la charge utile dans la demande HTTP.

Validation de réponse (validation du contenu)

Pour valider une chaîne de messages reçue du WebSocket, vous pouvez affirmer des mots clés dans le scénario d’exécution d’appel. Le système attend la réponse du point de terminaison cible et vérifie la présence du mot-clé spécifié dans la chaîne dans le message reçu jusqu’à ce que le délai d’achèvement de la tâche de surveillance soit atteint. Si le mot clé n’a pas été détecté dans les réponses de la prise, une erreur sera générée.

Dans les champs Mot-clé , vous pouvez spécifier un mot ou une expression que vous souhaitez rechercher dans le message de réponse. Utilisez le texte brut pour spécifier un mot-clé :

Notez qu’un mot clé est sensible aux cas.

Préparer le script et poster le script

Les champs peuvent contenir du code C#, qui peut être utilisé pour des demandes spécifiques et des données URL ou pour valider ou publier des en-têtes personnalisés. Veuillez consulter l’article Using Prepare Script and Post Script ou contacter le support technique pour plus de détails sur l’utilisation.

Le scénario dynamique de l’exécution d’appel WebSocket peut être spécifié dans le champ Préparer le script. Le scénario dynamique peut inclure un certain nombre d’opérations avec des données binaires ou des données de chaîne.

Opérations formatées binaires (msg comme Base64 codé):

  • ValidateBinary(string msg) – vérifie si une réponse WebSocket est égale aux données binaires spécifiées.
  • ValidateBinaryContains (string msg) – vérifie si une réponse WebSocket contient des données binaires spécifiées.
  • SendBinary (string msg) – envoie un message binaire à un WebSocket.

Opérations formatées par texte :

  • SendText (string msg) – envoie une chaîne de texte à un WebSocket.
  • ValidateText(string msg) – vérifie si une réponse d’un WebSocket est égale à une chaîne spécifiée.
  • ValidateTextContains(string msg) – vérifie si une réponse WebSocket contient une chaîne spécifiée.

Retarder:

  • Delay(string duration) – définit un délai entre les messages websocket en secondes au format suivant : XXs. Le système attend le temps spécifié avant d’exécuter l’opération suivante dans le script. Notez que des retards trop longs peuvent entraîner l’arrêt du script en raison du délai d’expiration de la tâche.

Dans les cas où toute assertion a été spécifiée dans le champ Préparer le script, le système attendra l’affirmation spécifiée dans la réponse et procédera à l’exécution du script une fois la validation réussie. Si un message contenant l’assertion spécifiée n’est pas reçu et que le délai d’achèvement de la tâche est atteint, nous générerons l’erreur de validation.

Dotcom-Monitor vous permet d’inclure autant d’opérations que nécessaire dans le script de préparation. Toutefois, si le délai d’achèvement de la tâche est atteint, l’exécution du script est arrêtée. Le temps d’exécution de la tâche est compté à partir du début de l’exécution du script.

  • Exemple : Validation de la réponse OK

  • Exemple : Échec de la validation de la réponse

  • Exemple : délai de 10 secondes

Notez que les champs Envoyer des données et de validation de contenu sont ignorés si le champ Préparer le script contient les étapes correspondantes dans le scénario dynamique. Par exemple, si les étapes suivantes sont incluses dans le script, le champ Envoyer des données et de validation du contenu sera ignoré :

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

Lorsque le paramètre CurrentTask ne dépend pas d’un nom de tâche et a le type de tâche qui est actuellement traitée.

Vérification SSL/Certificat

Secure Socket Layer SSL Certificate Monitoring est un aspect standard de la surveillance web.

Les options suivantes sont disponibles :

  • Autorité : vérifie si une chaîne de certificats contient un certificat racine digne de confiance ou non.
  • Nom commun (CN) : valide qu’une adresse à qui vous naviguez correspond au certificat d’adresse à qui l’adresse a été signée.
  • Date : vérifie la date d’expiration du certificat.
  • Révocation : valide que la chaîne de confiance du certificat ne contient pas de certificat révoqué.
  • Utilisation : vérifie l’utilisation inappropriée d’un certificat par une chaîne de certificats.
  • Rappel d’expiration en jours : rappel qui informe (par erreur) de l’expiration du certificat.
  • Certificat client :nom du certificat client.

Seuil de validation temporelle (en secondes)

Entrez le nombre de secondes pendant lesquelles la tâche doit attendre une réponse avant de mettre fin à la tâche et de renvoyer une erreur. Le délai d’expiration maximum est de 60 secondes. Si ce champ est laissé vide, le délai d’expiration par défaut de 60 secondes sera appliqué. Le temps d’exécution de la tâche est compté à partir du début de l’exécution du script.

Authentification de base

The HTTP authentication protocol is used to allow users to access content on some websites.

The following authentication schemes are available:

  • Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
  • Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
  • NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.

Once provided, login credentials will be passed along with the request header to the web server.

  • Username: contains a username for HTTP/S  authentication.
  • User Password: contains a password for HTTP/S authentication.

Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

En-têtes

L’option permet d’ajouter des en-têtes personnalisés supplémentaires si nécessaire.

  • Nom de l’en-tête: spécifiez le nom du paramètre tel qu’il apparaîtra dans la demande.
  • Valeur: entrez la valeur associée au nom du paramètre.

DNS Options

La fonction Options DNS permet aux utilisateurs de choisir comment les demandes de serveur de noms de domaine (DNS) sont effectuées au cours d’une tâche de surveillance.

Pour spécifier le mode de résolution des noms d’hôte, dans la section Mode Résolution DNS, sélectionnez l’un des modes disponibles. Pour plus de détails sur la configuration des fonctionnalités, consultez les options de mode DNS.

La section Hôtes DNS personnalisés permet de configurer le mappage des adresses IP aux noms d’hôte. La résolution DNS IPv6 et IPv4 est prise en charge.

Pour spécifier le mappage, entrez l’adresse IP et le nom d’hôte dans les champs correspondants.

Exemples:

192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com

Voir aussi : Options de mode DNS.