Utiliser des fonctionnalités réseau propres à la plateforme
La classe HttpClient fournit une abstraction de la connexion au réseau. Une application qui utilise cette classe est indépendante de la pile réseau de plateforme native. Les modèles .NET MAUI mappent la classe HttpClient au code qui utilise la pile réseau native de chaque plateforme. Cela permet à une application de tirer parti des fonctionnalités de configuration et d’optimisation du réseau qui sont propres à la plateforme. Cela est particulièrement important lorsque vous devez configurer une application cliente pour vous connecter de façon sécurisée à un service web REST.
Dans cette unité, vous allez apprendre à configurer une application cliente HTTP pour utiliser les fonctionnalités de protection réseau que fournit la plateforme sous-jacente.
Configurer App Transport Security sur iOS
App Transport Security (ATS) est une fonctionnalité iOS qui exige que toutes les communications réseau effectuées via la pile réseau HTTP native utilisent TLS 1.2 ou une version ultérieure. Les algorithmes de chiffrement modernes ne divulgueront pas d’informations si l’une des clés à long terme est compromise.
Si votre application ne satisfait pas à ces règles, l’accès au réseau lui sera refusé. Pour résoudre ce problème, vous avez deux options : changer votre point de terminaison de façon à respecter la stratégie App Transport Security, ou désactiver App Transport Security.
Pour désactiver la fonctionnalité App Transport Security, ajoutez une nouvelle clé appelée NSAppTransportSecurity au fichier Info.plist. Vous trouverez le fichier Info.plist dans le dossier iOS du projet dans le dossier Plateformes dans l'Explorateur de solutions. Cette clé est en fait un dictionnaire. Ajoutez une autre clé appelée NSExceptionDomains à ce dictionnaire. Cette clé contient un élément enfant pour chacun des points de terminaison à cibler. Chaque point de terminaison peut avoir sa propre configuration, qui spécifie les fonctionnalités à autoriser ou à refuser. Vous pouvez ajouter cette clé en utilisant l’éditeur plist générique dans Visual Studio ou en ouvrant la clé en tant que fichier XML.
Voici un exemple de configuration au format XML pour un point de terminaison :
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>dotnet.microsoft.com</key>
<dict>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>
Cet exemple ajoute une exception au point de terminaison sur dotnet.microsoft.com. Si vous déboguez un service localement sur votre ordinateur de développement, vous pouvez désactiver App Transport Security pour le trafic local, en utilisant la clé NSAllowsLocalNetworking comme suit :
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsLocalNetworking</key>
<true/>
</dict>
Si vous ne parvenez pas à identifier tous vos points de terminaison, désactivez App Transport Security pour tous les points de terminaison non spécifiés, en utilisant la clé NSAllowsArbitraryLoads :
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
Il y a d’autres options que vous pouvez ajouter pour préciser votre méthode de désactivation. Ces options ne sont pas expliquées dans ce module.
Configurer la sécurité réseau Android
Comme iOS, Android utilise un modèle de sécurité similaire pour les communications réseau. Ce modèle a été introduit avec Android 9 (niveau d’API 28). Le trafic en texte clair (non HTTPS) est désactivé par défaut lorsque votre application cible Android 9 (niveau d’API 28) ou une version ultérieure. Cette stratégie pourrait affecter votre cycle de développement si votre application doit télécharger une image ou un fichier sur un serveur qui n'a pas été configuré pour HTTPS. En outre, vous pourriez simplement essayer de déboguer votre application localement et ne pas souhaiter installer de certificats de développement. Vous pourriez avoir de fortes exigences professionnelles pour que tout le trafic web sur toutes les versions d'Android soit toujours HTTPS. La fonctionnalité de configuration de la sécurité réseau d'Android vous permet d'optimiser la sécurité du trafic dans une application.
Autoriser le trafic en texte clair
Pour autoriser le trafic en texte clair, créez un nouveau fichier XML dans le dossier Resources/xml nommé network_security_config.xml (il se peut que vous deviez également créer le dossier xml). Le dossier Resources se trouve dans le dossier de la plateforme Android dans l'Explorateur de solutions. Dans ce fichier, ajoutez un élément network-security-config avec un élément enfant domain-config. La configuration suivante autorise le trafic en texte clair pour un domaine spécifique et une adresse IP :
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">10.0.2.2</domain> <!-- Debug port -->
<domain includeSubdomains="true">microsoft.com</domain>
</domain-config>
</network-security-config>
Vous pouvez renforcer la sécurité de votre application en limitant le trafic de texte clair sur toutes les versions d'Android, quel que soit la version cible de .Net Framework. Pour ce faire, définissez la propriété cleartextTrafficPermitted de l'élément domain-config sur false. Ce paramètre de configuration bloque tout le trafic non HTTPS.
Pour que l’application reconnaisse le fichier network_security_config.xml, configurez la propriété networkSecurityConfig du nœud application dans le fichier AndroidManifest.xml situé dans le dossier Properties :
<?xml version="1.0" encoding="utf-8"?>
<manifest>
<application android:networkSecurityConfig="@xml/network_security_config" ...></application>
</manifest>
Vous pouvez spécifier des options supplémentaires si vous devez préciser la méthode de désactivation de la sécurité du transport.
Déboguer des applications localement
L’un des grands avantages de la création des applications mobiles avec Visual Studio est la possibilité d’exécuter et de déboguer ces applications mobiles à l’aide du simulateur iOS ou de l’émulateur Android. Ces applications peuvent consommer des services web ASP.NET Core qui sont exécutés localement et sont exposés via HTTP.
Les applications qui s’exécutent dans le simulateur iOS peuvent se connecter à des services web HTTP locaux en utilisant l’adresse IP de votre ordinateur ou le nom d’hôte localhost. L’application doit désactiver la fonctionnalité ATS en spécifiant au minimum NSAllowsLocalNetworking. Par exemple, si un service web HTTP local expose une opération GET via l’URI relatif /api/todoitems/, une application exécutée dans le simulateur iOS peut consommer l’opération en envoyant une requête GET à http://localhost:<port>/api/todoitems/.
Les applications exécutées dans l’émulateur Android peuvent se connecter aux services web HTTP locaux en utilisant l’adresse 10.0.2.2. Cette adresse est un alias pour l’interface de bouclage de l’hôte (127.0.0.1 sur votre ordinateur de développement). Une configuration de sécurité réseau doit également être configurée pour cette adresse IP spécifique. Par exemple, si un service web HTTP local expose une opération GET via l’URI relatif /api/todoitems/, une application exécutée dans l’émulateur Android peut consommer l’opération en envoyant une requête GET à http://10.0.2.2:/api/todoitems/.
Notes
Les services web ASP.NET Core qui sont testés sur l’hôte local doivent désactiver les redirections HTTPS en commentant l’instruction app.UseHttpsRedirection(); dans le fichier Startup.cs.
Détecter le système d’exploitation
Avec la classe DeviceInfo, une application peut déterminer sur quelle plateforme elle s’exécute. Dans l’exemple suivant, l’application définit la variable BaseAddress sur une valeur différente, selon qu’elle s’exécute sur Android :
public static string BaseAddress = DeviceInfo.Platform == DevicePlatform.Android ? "http://10.0.2.2:5000" : "http://localhost:5000";
public static string TodoItemsUrl = $"{BaseAddress}/api/todoitems/";