Comment Сreate Dispositifs et cibles

Une surveillance HTTP/S vérifie la disponibilité, les performances, le contenu approprié et les erreurs d’une seule URL. Il prend en charge les demandes POST et GET, les cookies, les soumissions de formulaires, les en-têtes personnalisés, les sites sécurisés par mot de passe (autorisation http/s de base ainsi que les mécanismes d’autorisation de cookie/script) et les seuils de délai d’attente.

La surveillance HTTP/S valide les certificats de sécurité, vérifie l’autorité du certificat et vérifie l’expiration. Il peut également être configuré pour vous envoyer des rappels à l’approche de la date d’expiration du certificat.

Vous pouvez convertir les paramètres de demande HTTP(S) en paramètres contextatifs pour passer dans les valeurs, par exemple, récupérées à partir d’une réponse d’une autre demande dans le dispositif de surveillance. Vous pouvez configurer les paramètres de contexte de l’URL, des en-têtes, du contenu de demande (pour les méthodes Post, Put, Patch) et des scripts de préparation et de publication. Pour plus de détails, voir Comment utiliser les paramètres de contexte dans les requêtes HTTP(S).

Configuration d’une demande

Url

Entrez l’URL de la page sur qui vous souhaitez effectuer la tâche. Il doit être formaté en tant que tel : www.example.com. Vous pouvez activer un mode d’entrée visuellement convivial en cliquant sur l’interrupteur détaillé en haut de la section.

Vérification SSL/Certificat

Secure Socket Layer SSL Certificate Check est un aspect standard des tests HTTP(S).

Les options supplémentaires 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.

Voir aussi : Nom d’hôte cible ou adresse IP.

Délai d’achèvement (en quelques secondes)

Entrez le nombre de secondes que la tâche doit attendre pour une réponse de la page Web avant de mettre fin à la tâche et de retourner une erreur. Si cela reste vide, le délai d’attente par défaut pour une tâche est de 120 secondes.

Type de demande

Vous pouvez envoyer une demande GET ou POST sur la page Web. La sélection d’une demande GET permettra simplement de récupérer des données à partir du serveur Web. La sélection d’une demande POST indique que vous y compris un ensemble de données sur lequel le serveur peut agir.

Si vous définissez le type de demande sur POST mais ne spécifiez pas un paramètre POST dans la section paramètres supplémentaires ci-dessous, la valeur POST sera par défaut pour get lors de l’enregistrement de la tâche.

Url Redirige

Si l’option Suivez redirections est définie sur Oui,le système suivra le chemin de l’URL envoyée avec la réponse 301 et considérera chaque redirection comme une demande HTTP distincte. Il vous permet de suivre la chaîne de redirection complète (tous les liens que la demande est redirigée à travers) dans les résultats des tests, y compris les temps de réponse à la fois pour l’URL initiale et les réponses ultérieures.

Nous vous recommandons de laisser l’option Follow Redirects activée si vous avez besoin de tester non seulement l’URL initiale, mais toutes les URL de la chaîne. Par exemple, il peut être utile d’effectuer une vérification de certificat SSL pour chaque URL d’une chaîne de redirection.

Dans les cas où vous souhaitez tester une URL initiale uniquement, désactiver l’option Suivez redirections.

Notez qu’une limite de redirection par défaut est définie à 10 redirections. Si vous souhaitez que le système exécute un nombre particulier de redirections (moins de 10), vous pouvez spécifier le nombre d’URL que vous souhaitez tester dans votre chaîne de redirection dans le champ Préparer le script :

string url;
url = "http://wtatour.com/";
(current.Task).TaskMaxRedirectAttempts = N;

N est le nombre d’emplacements de redirection que nous voulons suivre. Pour ne pas suivre les redirections, il suffit de définir le nombre d’emplacements de redirection vers 0.

Validation du contenu

Les mots clés de validation de contenu sont utilisés pour s’assurer que le contenu attendu a été chargé sur une page Web. Dans les champs Mots clés, vous pouvez spécifier un ou plusieurs mots ou expressions que vous souhaitez rechercher dans le contenu de la page Web. Si les mots clés attendus ne sont pas trouvés, la tâche retournera une erreur.

Vous pouvez entrer plusieurs chaînes dans les champs de mots clés. Les valeurs que vous entrez peuvent être séparées par des expressions logiques comme suit :

{[("keyword1"&"keyword2")|!"keyword3"]}

où:
{[ – début de l’expression des mots clés;
]} – fin de l’expression des mots clés;
() – crochets de regroupement;
et – logique ET;
| – ou logique;
! – logique NON;
«string» – un mot clé.

Une expression de mot clé réussie doit inclure les supports de début et de fin comme suit :

{["keyword"]}

Authentification de base

Le système d’authentification de base est utilisé pour permettre aux utilisateurs d’accéder au contenu sur certains sites Web. Une fois fournies, les informations d’identification de connexion seront transmises avec l’en-tête de demande au serveur Web.

  • Nom d’utilisateur : contient un nom d’utilisateur pour l’authentification d’accès de base ou digeste HTTP/S.
  • Mot de passe utilisateur : contient un mot de passe pour l’authentification d’accès de base ou digeste HTTP/S.

Ne confondez pas l’authentification de base avec d’autres schémas d’authentification tels que l’authentification du porteur qui implique des jetons porteurs et OAuth 2.0 qui utilise des jetons d’accès.

Lisez les articles sur le nom d’utilisateur et le mot de passe d’authentification de base et surveillez les API basées sur OAuth 2.0 pour plus d’informations.

En-têtes

L’option permet d’ajouter des en-têtes personnalisés supplémentaires. Par exemple, vous pouvez définir le type MIME des données envoyées avec la demande dans l’en-tête de type contenu :

Content-Type: text/html

Si l’en-tête de type contenu n’est pas spécifié pour la demande, la demande sera envoyée avec l’application de type de contenu par défaut/x-www-form-urlencoded.

L’en-tête utilisateur-agent par défaut est défini sur :

Utilisateur-Agent: Mozilla/5.0 (compatible; MSIE 10,0; Windows NT 6.1; Trident/6.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) DMBrowser/2.1 (SV)

Toutefois, la chaîne utilisateur-agent peut être remplacée par n’importe quelle autre chaîne. Pour ce faire, ajoutez un en-tête personnalisé avec le nom «user-agent» et la valeur spécifique nécessaire.

DONNÉES POST (PUT, PATCH)

Si l’une des méthodes POST, PUT ou PATCH a été sélectionnée, vous pouvez spécifier la charge utile ici. Le contenu de l’organisme de demande HTTP peut être envoyé sous forme de données « brutes » (JSON, XML, etc.) ou de collecte statique de valeur nommative (Données de formulaire).

Pour travailler avec une collection de valeur nom-valeur, vous pouvez activer le mode d’entrée détaillé en utilisant l’interrupteur détaillé en haut de la section et fournir des noms de paramètres de demande et des valeurs dans le champ correspondant.

Pour envoyer des données « brutes » avec la demande, comme un objet JSON, entrez votre charge utile JSON dans le champ d’entrée. Vous pouvez également modifier dynamiquement le corps de demande. Par exemple, si vous devez envoyer la date et l’heure actuelles dans le cadre de votre demande POST ou passer l’ID de session en cours dans la charge utile JSON à un serveur distant. Dotcom-Monitor permet de modifier dynamiquement la charge utile de la demande HTTP en utilisant la syntaxe Razor et les masques de données.

  • exemple. Organe JSON dynamique pour les demandes de poste HTTP

    Pour mieux comprendre comment fonctionne le corps Dynamic JSON dans la demande HTTP, jetons un coup d’œ coup d’œuvre à l’exemple suivant. Supposons que nous devons soumettre une commande sur un site Web et que la transaction de soumission comprend trois étapes de base exécutées séquentiellement :

    1. connectez-vous
    2. enregistrement
    3. Soumission de commande

    Pour configurer un test avec ces étapes exécutées séquentiellement, nous devons créer trois tâches HTTP au sein d’un seul dispositif de surveillance (ou test de charge, si des tests de charge ont lieu).

    Supposons que nous devons envoyer l’heure actuelle et un GUID unique dans le JSON avec la demande HTTP pour vérifier avec l’application. En outre, pour soumettre une commande, un ID de session utilisateur généré lors de la connexion et un temps de commande est requis par l’application.

    Pour implémenter ce test, nous devons d’abord configurer une demande de connexion avec des paramètres d’authentification de base sur le serveur Web de l’application Web. Ensuite, nous devons configurer une demande HTTP pour passer l’heure d’enregistrement réelle et guid unique avec un organisme JSON. Pour cet exemple, nous entreons la chaîne suivante à l’aide de la syntaxe Razor dans le corps JSON :

    { "CheckInTime": "@Model["CurrentTime"]", "GenGuid": "@Model["Guid"]" }

    Lorsque @Model[» Nom de < paramètre > «] fait référence à un nom de paramètre de contexte nécessaire dans l’expression Razor.

    Nous devons déclarer les paramètres du contexte et préciser comment les données postales doivent être traitées dans le champ Préparer le script :

    context.Guid = Guid.NewGuid().ToString(); // uniq random string
    context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // get current time in UTC
    ProcessPostDataByRazor(currentTask); // the call to process the Post Data content with the Razor engine

    La demande HTTP de résultat ressemblera à ceci :

    03:15:23
    POST http://www.dotcom-monitor.com/CheckIn
    { "CheckInTime": "2021-03-30T08:15:22.0Z", "GenGuid": "5c5e3d23-66fd-49d0-bd57-62c516aea7e7" }

    Dans l’étape suivante, nous devons configurer la demande HTTP pour soumettre une commande. Pour ce faire, nous transmettons l’heure actuelle de l’ordre et l’ID de session, ainsi que le numéro d’identification du modèle de l’élément, dans l’organisme JSON au point de terminaison cible. Voir l’organisme JSON pour cette demande ci-dessous:

    { "OrderTime": "@Model["OrderTime"]",   "VIEWSTATE": "@Model["Session"]",  "ModelID": "2128506" }

    Pour passer une valeur de la variable d’identification de session en cours, nous devons la récupérer à partir de la page de connexion, appelée à la première étape de connexion, en utilisant la méthode Afficher l’état. Il peut être codé dans le script de préparation. En outre, pour simuler le temps de réflexion d’un utilisateur réel, nous allons définir la variable de temps de commande avec un décalage de trois minutes. Par conséquent, le champ Préparer le script contiendra les chaînes suivantes :

    context.OrderTime = DateTime.Now.AddMinutes(3).ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // order time + 3 min
    context.Session = (Tasks["Login"] as Http).body["//INPUT[@ID='__VIEWSTATE']", "VALUE"]; // track state value from Login page 
    ProcessPostDataByRazor(currentTask);

    La demande HTTP qui en résultera ressemblera à ceci :

    03:15:45
    POST http://www.dotcom-monitor.com/Order
    { "OrderTime": "2021-03-30T08:18:45.0Z", "VIEWSTATE": "<Server Generated ViewState>", "ModelID": "2128506" }
                        

Pour savoir comment configurer une demande HTTP avec une charge utile en évolution dynamique, voir Comment modifier dynamiquement la charge utile dans la demande HTTP.

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 contient les mappages des adresses IP aux noms d’hôtes.

Pour spécifier la cartographie, entrez l’adresse IP et le nom de l’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.

Préparer le script et poster le script

Les champs peuvent contenir du code C#, qui peut être utilisé pour des données POST, GET, URL spécifiques 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.