[MUSIQUE]
Parlons dans un langage CORS maintenant.
Maintenant, qu'est-ce exactement le partage de résultats d'origine croisée, et
pourquoi est-il pertinent lorsque nous examinons les applications Web et les
applications hyper-mobiles comme nous l'avons fait dans cette spécialisation ?
Comme vous le comprenez, la plupart des pages Web extraient maintenant des données de
nombreux sites différents afin de construire une page Web.
Maintenant, afin d'imposer une politique stricte d'accès aux ressources de différents sites,
la même politique d'origine a été imposée par de nombreux navigateurs.
Nous en parlerons un peu plus en détail dans les prochaines diapositives, mais
dans le contexte des frameworks dont nous avons discuté dans cette
spécialisation particulière, comme Angular, Ionic et NativeScript,
beaucoup d'entre eux impliqueront des scripts, du code JavaScript,
qui pourraient devoir accéder aux ressources de différents sites.
Et c'est là que le problème CORS surgit très facilement.
Voyons comment nous allons aborder cette question plus en détail dans cette conférence et
l'exercice qui suit.
J' ai brièvement fait allusion à la politique de même origine que j'ai entamée cette conférence.
Maintenant, la stratégie de même origine est un modèle de sécurité d'application Web
qui limite la façon dont un document ou un script
chargé à partir d'une origine interagira avec les ressources d'une autre origine.
Le but de cette opération est d'isoler les documents potentiellement malveillants.
Maintenant, évidemment, lorsque vous avez une page Web qui implique un script, du
code JavaScript, qui pourrait accéder à des ressources à partir d'un autre emplacement, du
code potentiellement malveillant pourrait être injecté dans votre page Web et ainsi
accéder à une origine différente de celle d'où votre page Web est obtenue.
Maintenant, c'est la raison pour laquelle de nombreux navigateurs imposent cette politique de même origine.
Maintenant, quand nous parlons de même origine, comment pouvons-nous spécifier une origine ?
Maintenant, dans ce contexte, une origine pour n'importe quelle ressource est définie par trois tuples.
Tout d'abord, le protocole utilisé pour accéder à la ressource.
Deuxièmement, le nom d'hôte de la ressource, ou le domaine de cette ressource.
Et troisièmement, le numéro de port auquel cette ressource est accessible.
C' est ainsi que nous identifions l'origine de n'importe quelle ressource. La
ressource dans ce cas pourrait être une page html, une image, des
données JSON obtenues à partir d'un point de terminaison de l'API REST, et bien d'autres encore.
Pour plus de détails sur la politique de même origine, regardons un exemple.
Supposons que nous ayons une page Web qui est chargée à partir de ce site répertorié ici
, www.abc.com, et dans un dossier xyz, et
le page.html étant chargé ici.
Cette page peut impliquer des liens ou même du code JavaScript qui pourraient
émettre XMLHttpRequest vers d'autres ressources sur la page Web.
Maintenant, dans ce cas, si nous essayons d'accéder à une autre URL
, par exemple, la première listée ici, qui évidemment vous voyez
provient du même site mais d'un dossier différent.
Ceci est acceptable, car l'origine, dans ce cas,
le protocole utilisé et le numéro de port, restent les mêmes.
Donc, cela est acceptable pour accéder à cette ressource.
De même, dans le second cas, nous pourrions avoir sous
plusieurs niveaux de sous-dossiers une ressource qui est accessible.
Mais encore une fois, puisque leur origine reste la même, ce qui est acceptable.
Mais regardons le troisième exemple ici.
Dans cet exemple, nous voyons que nous essayons d'accéder à une ressource ici avec
le protocole https, ce qui viole évidemment le principal de même origine
parce que nous utilisons un protocole différent pour accéder à cette ressource à ce stade.
Ce serait donc considéré comme un échec dans ce cas.
Le quatrième cas est où nous accédons à une ressource avec un numéro de port différent.
Et le cinquième cas est où nous accédons à une ressource sur un autre hôte.
Maintenant, tous ces trois seraient marqués comme non valides ou
ne peuvent pas être accessibles sous cette politique de même origine.
Donc, si vous imposez la même stratégie d'origine pour l'accès à partir, par exemple, de
votre XMLHttpRequest, alors les trois derniers ne seraient pas autorisés dans ce cas.
Mais bien sûr, il y a beaucoup de situations où ce concepteur de site
peut réellement héberger des ressources sur différents sites, peut-être sur différents domaines,
et être toujours capable d'extraire les données afin de construire la page Web ou de
faire fonctionner l'application Web ou de faire fonctionner l'application mobile hybride .
Donc, pour tenir compte de ces situations, le
traitement des demandes d'origine croisée est une méthode qui nous permet d'accéder à ces ressources.
Nous considérons donc une demande comme une
demande d'origine croisée si vous essayez d'accéder à une ressource à partir d'un domaine différent,
ou à un numéro de port différent, ou avec un protocole différent.
Alors, comment pouvons-nous tenir compte des situations où il s'agit d'un accès légitime à une ressource,
mais en raison de la politique de même origine,
votre navigateur refusera de charger cette ressource ?
Maintenant, c'est là que, comme je l'ai mentionné, de
nombreux navigateurs vont restreindre les requêtes http d'origine croisée,
en particulier celles qui sont initiées par XMLHttpRequest ou
le protocole Fetch pour récupérer des données.
Ceux-ci sont pertinents lorsque nous y accédons à partir de notre code JavaScript.
Donc, dans ces circonstances, il est logique d'imposer la politique de même origine,
mais alors nous devrions avoir un moyen de contourner la situation où
une demande légitime peut être émise.
C' est là que
nous aidons l'approche CORS, l'approche de partage des ressources entre les origines.
Ce CORS est donc un mécanisme qui permet aux serveurs Web d'effectuer des requêtes
inter-domaines, ou des demandes d'origine croisée.
Donc, ici, le navigateur et le serveur
d'où vous essayez de réparer la ressource interagiront les uns avec les autres
, puis arriveront à un accord disant que cet accès est acceptable et autorisé.
Donc, une fois que l'accord est atteint,
alors cette demande peut être autorisée par votre navigateur.
Ainsi, le navigateur et le serveur interagiront les uns avec les autres afin de
déterminer si cet accès à cette ressource est une situation acceptable.
C' est donc là qu'un nouvel ensemble d'en-têtes HTTP a été
introduit dans les messages de réponse HTTP provenant du côté serveur.
Ces en-têtes permettent aux serveurs de décrire l'ensemble des origines
auxquelles le serveur est autorisé à accéder par le navigateur.
Et à son tour, le navigateur se rend compte que ces accès
aux ressources sont acceptables pour être autorisés, même s'ils violent cette
politique d'origine identique que nous avons vu précédemment.
Donc, dans ce cas, nous avons des en-têtes comme, par exemple,
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,
Access-Control-Allow-Headers, Access-Control-Allow-Methods, et
quelques autres que le serveur utilise pour informer le navigateur, disant que
c'est un moyen acceptable d'accéder à la ressource du côté du navigateur.
Et lorsque le navigateur voit ces messages de réponse entrants du côté serveur,
le navigateur accepte et permet l'exécution de cette demande d'origine croisée.
Maintenant, cela signifie également que le serveur doit être configuré pour pouvoir
répondre avec ces champs d'en-tête et
les informations d'en-tête incluses dans le message de réponse venant du côté serveur.
Maintenant, c'est là que nous divisons toutes les demandes d'origine croisée en
plusieurs catégories.
Nous avons le premier étant la simple requête inter-site.
Dans les requêtes intersites simples, vous pouvez utiliser le GET ou le
POST avec le corps de la requête.
Mais lorsque vous utilisez le POST, votre corps de requête doit contenir
soit Application/X-WWW-URLENcoded,
soit multipart/form-data, ou text/plain.
Ensuite, il est traité comme une simple requête inter-site et
aucun en-tête personnalisé ne sera autorisé dans ce cas.
Donc, dans ce cas, il est acceptable pour le serveur d'informer le client, en
disant que cela est autorisé et le navigateur devrait autoriser de telles requêtes.
Ainsi, par exemple, pour les ressources largement accessibles, comme, par exemple,
si vous effectuez une requête GET à un serveur afin de récupérer les données afin de
construire l'interface utilisateur, alors peut-être que la requête GET est acceptable
quelle que soit l'origine de cette demande.
Donc, dans ce cas, votre serveur répondra au client, en
disant Access-Conrol-Allow-Origin, avec cette étoile générique ici,
ce qui signifie que toute origine de la requête est acceptable, et que
le navigateur devrait autoriser la requête à être effectuée sur ce serveur.
Et maintenant, vous pouvez également restreindre l'accès à l'origine.
Dans ce cas, vous pouvez spécifiquement dire que si l'origine est
un site particulier, alors il est acceptable de traiter cette demande.
Ainsi, le navigateur voit que l'envoi de requêtes
avec ce site d'origine particulier dans la requête est acceptable et
nous allons autoriser la requête d'origine croisée.
Ainsi, vous pouvez contrôler la façon dont l'origine est
spécifiée dans le message de demande venant du côté client.
Ainsi, le serveur est en mesure d'accepter de telles requêtes.
Certaines autres demandes seraient classées dans la catégorie des demandes préréglées.
Dans la requête avancée, vous vous attendez à ce qu'avant que le client
envoie la demande réelle, le client envoie une requête en amont,
ce qui signifie qu'il contacte le serveur pour obtenir des
informations du serveur avant que la demande réelle ne soit émise.
C' est spécifiquement le cas où vous émettez des requêtes PUT et DELETE
car les requêtes PUT et DELETE peuvent provoquer des modifications côté serveur.
Et donc toute méthode qui provoque des effets secondaires sur les données du serveur, comme la
requête PUT et DELETE, est spécialement mandatée pour suivre l'approche en amont.
Dans l'approche en amont, l'idée est que le client
enverra d'abord une requête HTTP OPTIONS côté serveur, et
en réponse à ce message de demande OPTIONS du côté client, le serveur
répondra avec les Access-Control-Allow-Headers correspondants,
Access-Control-Allow-Origin, et les
informations d'en-tête Access-Control-Allow-Credentials dans la réponse à un message OPTIONS. Par la
suite, le client décidera s'il peut émettre la demande d'origine croisée ou
non en fonction de la réponse à la demande de prévol OPTIONS envoyée par le client.
C' est donc là que vous devez passer par deux étapes avant que votre demande
puisse être autorisée et gérée par le côté serveur.
Une troisième catégorie de demandes CORS serait ce qu'on appelle les demandes d'informations d'identification,
où vous attendez que le client inclue des informations d'identification dans l'en-tête
du message de demande.
Ainsi, les demandes qui sont accompagnées de cookies, par exemple, pour
reconnaître la session sur le côté serveur, ou une sorte d'
informations d'authentification HTTP dans l'en-tête d'autorisation dans le message de demande.
Donc, dans ce cas, le serveur doit répondre avec
Access-Control-Allow-Credentials : true pour le côté client.
Donc, dans ce cas, le serveur répondra avec ceci et
le client sera autorisé à envoyer ses
informations d'identification dans la requête entrante du côté client.
Maintenant, dans ce cas, l'Access-Control-Allow-Origin n'est pas autorisé
à avoir le caractère générique, l'étoile, dans le message de réponse.
Il est prévu de spécifier explicitement l'origine vers
laquelle la demande peut être lancée.
Maintenant, évidemment, nous pouvons implémenter une grande partie du travail,
ce que nous devons faire du côté serveur, en implémentant notre propre middleware si nous
choisissons de gérer les réponses liées au CORS du côté serveur.
C' est très simple, comme nous l'avons vu dans le code que nous avons implémenté.
Bien sûr, c'est une façon de gérer les réponses liées au CORS du côté serveur,
mais heureusement, nous avons un CORS NoDemodule spécifique
qui est conçu pour gérer ce genre de
travail que le serveur doit faire pour répondre aux exigences CORS.
Ainsi, le CORS NoDemodule nous permet de configurer le CORS côté serveur,
y compris en spécifiant les informations d'origine où les informations d'identification seraient acceptées
et beaucoup d'autres informations telles que vous pouvez configurer le serveur
pour pouvoir gérer les réponses liées au CORS qu'il doit donner
au navigateur en réponse au message de demande.
Pour installer CORS NoDemodule, évidemment, vous voyez npm installer cors,
puis configurer le middleware CORS dans votre application express.
Le module CORS lui-même fournit un moyen très simple d'activer CORS.
Vous pouvez simplement inclure l'utilisation de l'application CORS avec des crochets vides,
ce qui signifie essentiellement que vous ouvrez votre serveur, et il répondra avec
l'Access-Control-Allow-Origin avec l'étoile générique à chaque requête entrante.
Mais lorsque vous configurez votre serveur, vous pouvez vouloir plus de contrôle sur cela, de sorte
que nous pouvons spécifier des options supplémentaires pour le CORS.
Et non seulement cela, vous pouvez imposer la gestion CORS
différemment pour différentes routes au sein de votre serveur.
Ainsi, comme nous le verrons dans l'exercice, nous imposerons différentes exigences CORS
sur les différentes routes côté serveur, et tout cela est configuré en utilisant
diverses options de configuration que CORS NoDemodule prend en charge pour nous.
Ainsi, en utilisant CORS NoDemodule, il est très facile de configurer votre serveur pour gérer
toutes les demandes d'origine croisée provenant de votre client
, puis de répondre avec les informations d'en-tête
appropriées côté client avec les en-têtes CORS appropriés dans le message de réponse du côté serveur.
Avec cette compréhension rapide de CORS,
je suis sûr que vous avez plus de questions à ce stade que les réponses de cette conférence.
Mais si vous souhaitez lire beaucoup plus de détails sur CORS,
je vous ai fourni des ressources supplémentaires à la fin de cette leçon,
qui vous permettent d'en savoir plus sur CORS lui-même.
Mais du point de vue de ce cours, nous aimerions configurer notre
application express que nous avons développée jusqu'
à présent pour gérer les questions liées au CORS côté serveur.
Pour passer à l'exercice, nous allons installer le module CORS npm,
puis le configurer sur différentes routes au sein de notre serveur supplémentaire.
[ MUSIQUE]