[MUSIQUE]
Dans la leçon précédente, nous avons appris sur l'authentification de base.
Nous avons vu que dans l'authentification de base, le client devra explicitement continuer à
ajouter dans le champ d'autorisation contenant le nom d'utilisateur et le
mot de passe pour chaque requête que le client envoie au côté serveur.
Maintenant, c'est parfaitement bien pour une authentification simple.
Les cookies sont encore un autre mécanisme qui est fourni qui permet
à votre serveur de pouvoir s'attendre à ce
que le client stocke certaines informations côté client et inclut explicitement ces informations dans chaque requête sortante.
Donc, au lieu d'inclure votre nom d'utilisateur et votre mot de
passe codés en base 64 comme nous l'avons fait dans l'authentification de base, en utilisant
des cookies, votre serveur peut configurer une information explicite du côté client
qui sera ensuite incluse dans chaque demande sortante du côté client.
Maintenant, si votre serveur veut suivre les informations sur votre
client, le serveur peut configurer explicitement un mécanisme de suivi de session.
Maintenant, les cookies sont petits et ne peuvent pas stocker beaucoup d'informations là-dedans,
et cela, bien sûr, ne peut pas être inclus dans la demande sortante.
Les cookies peuvent inclure des informations de base
dans l'en-tête de la demande sortante du client.
Maintenant, si nous voulons que beaucoup plus d'informations soient suivies sur un client
côté serveur, alors les sessions express nous permettent de le faire.
Étudions plus sur les cookies et les
sessions Express un peu plus en détail dans cette leçon et
explorons-les plus loin dans les exercices qui suivent cette conférence.
Alors, que sont les cookies HTTP ?
Les cookies HTTP, comme je l'ai mentionné, sont un petit morceau de données qui est envoyé
à partir d'un serveur Web et est stocké du côté client.
Maintenant, presque tous les navigateurs ont la possibilité de prendre en charge
le stockage des cookies côté client, et de les inclure automatiquement
dans la demande lorsque la demande est envoyée à un serveur spécifique.
Ainsi, chaque requête suivante du
côté client inclura un nouvel en-tête là-dedans
avec le cookie dans l'en-tête de la requête.
Maintenant, évidemment, si vous avez vu la presse populaire
y avoir eu une mauvaise réputation, ce n'est, bien sûr, pas tout à fait injustifié.
Mais il est soufflé loin de proportion que ce qui est vraiment la vérité.
Alors prenez tout ce que vous lisez dans la presse populaire sur les cookies et
leur mauvaise réputation avec un grain de sel.
Les cookies sont très utiles pour faire beaucoup de choses intéressantes.
Et nous pouvons nous assurer que les cookies peuvent avoir une
intégrité suffisante pour qu'ils ne puissent pas être manipulés par quiconque entre les deux.
Maintenant, comment fonctionne cette inclusion de paramètre de cookie dans la requête sortante ?
Lorsqu' un client envoie une requête au site serveur,
si le client est authentifié sur le site serveur.
Par exemple, en utilisant l'authentification de base
, le serveur peut en retour, configurer un cookie.
Maintenant, pour configurer un cookie sur le site du client, le serveur inclura dans
le message de réponse un en-tête avec l'en-tête du cookie envoyé et
le cookie réel dans l'en-tête.
Maintenant, lorsque le client reçoit le message de réponse
du serveur contenant l'en-tête Set-Cookie, il va configurer le cookie côté client.
De telle sorte que chaque requête suivante allant du côté client
inclura explicitement un champ d'en-tête appelé comme cookie et l'
en-tête réel qui contient comme valeur,
les informations de cookie qui ont été envoyées par le serveur dans le message de réponse.
Ainsi, chaque message de demande suivant portera ce cookie dans l'en-tête.
Ainsi, lorsque le serveur reçoit ce message de requête, il est capable d'examiner
le cookie et de supposer d'où provient cette requête.
Ainsi, il est capable de reconnaître le client en regardant les informations sur les cookies.
C' est donc là que les cookies s'avèrent très utiles
pour envoyer des informations d'autorisation.
Donc, en servant incluant le nom d'utilisateur et le mot de passe comme partie de l'
en-tête d'authentification de base dans chaque demande en cours.
La première fois que vous vous authentifiez, vous envoyez votre nom d'utilisateur et votre mot de passe et
le serveur installe le cookie de votre côté.
Par la suite, il vous suffit d'inclure le cookie dans la demande sortante.
Maintenant, les cookies peuvent également avoir une date d'expiration associée à eux.
Ainsi, à ce stade, le cookie sera considéré comme expiré et
ne sera plus valide.
C' est donc une façon de contrôler la durée pour
laquelle une autorisation est valide.
En arrivant à Express lui-même, comment Express prend-il en charge les cookies ?
Maintenant, comme nous le comprenons, Express utilise beaucoup de middleware.
C' est là que l'un des middlewares qui vient en appelé l'analyseur de cookies
arrive à notre application à huit heures.
L' analyseur de cookies permet au serveur de configurer un cookie dans l'en-tête de réponse.
Donc, cela se fait en utilisant res.cookie et le nom et
certaines valeurs et les options comme nous le verrons dans l'exercice plus tard.
Et donc les cookies, lorsqu'ils sont envoyés du côté client, inclus dans ce
message de demande, sont analysés du côté serveur Express, en utilisant l'analyseur de cookies.
Le middleware cookie-parser,
qui, une fois installé, vous permettra d'analyser les cookies entrants.
Et puis ces cookies entrants seront ajoutés dans
la demande en tant qu'en-tête et peuvent être examinés côté serveur.
Maintenant, afin de protéger l'authenticité du cookie,
les cookies eux-mêmes peuvent être signés par le serveur.
Maintenant, lorsque le serveur signe un cookie, le serveur utilise une clé secrète,
qui n'est connue que du côté serveur.
Maintenant, si vous savez quelque chose sur la sécurité informatique, la cryptographie et le
cryptage, alors vous comprenez ce que
signifient la signature, les clés secrètes et les clés publiques et toutes ces choses.
Si vous ne le faites pas, il suffit de dire qu'une clé secrète est
une chaîne spécifique que seul le serveur connaît et que personne d'autre ne sait.
Ainsi, lorsqu'un serveur crypte un cookie, il utilise une clé secrète comme signature et
crée ce qu'on appelle un code d'authentification de message de hachage clé.
Et inclut ceci dans ce cookie qui est envoyé du serveur vers le côté client.
Ce HMAC qui est créé côté serveur ne peut être fait
que par ce serveur spécifique connaissant cette clé secrète.
Maintenant, puisque le serveur est une ressource protégée,
seul le serveur connaîtra la clé secrète et il est donc très facile de vérifier
quand un cookie signé est envoyé du côté client au côté serveur.
Ainsi, lorsque le cookie signé est envoyé du côté client au côté serveur,
le cookie sera configuré du côté client,
puis toutes les demandes suivantes incluront ce cookie signé du côté client.
Maintenant, le middleware de l'analyseur de cookies que nous avons mis en place avec notre serveur Express
prend déjà en charge les cookies signés.
Maintenant, pour cela, dans l'analyseur de cookies, vous fournirez également la clé secrète comme
paramètre pour l'analyseur de cookies lorsque vous configurez le middleware de l'analyseur de cookies.
Ainsi, tous les cookies seront signés de manière appropriée, puis envoyés.
Et lorsque le cookie est analysé côté serveur dans le
message de demande entrante, il sera ajouté dans le message de demande en tant que req.signedCookies.
Et puis vous pouvez avoir un champ spécifique que vous pouvez enregistrer dans le cookie signé.
Les cookies sont un moyen très utile pour
que votre client puisse envoyer des informations par lesquelles votre serveur reconnaît le client.
Mais bien sûr, les cookies ont des limites.
Ils ont une taille fixe, de sorte qu'ils ne peuvent pas encoder beaucoup d'
informations sur le client que leur serveur peut récupérer à partir du cookie.
Le cookie est utilisé pour rappeler au serveur
quel client envoie la requête.
Maintenant, si vous voulez avoir un mécanisme plus élaboré pour suivre les informations sur
un client, alors du côté serveur, vous pouvez configurer ce que l'on appelle des sessions.
Désormais, les sessions sont un mécanisme générique disponible avec tous les serveurs.
En particulier, nous examinerons Express lui-même et
comment Express prend en charge la gestion des sessions côté serveur.
La façon dont cela fonctionne est que la session utilisateur est configurée côté serveur.
Donc, cette session elle-même est une combinaison d'un cookie et
d'un ID de session, et le côté serveur suit les informations
associées à cet ID de session, ou indexées par cet ID de session.
Les informations de session elles-mêmes peuvent avoir n'importe quelle
quantité d'informations faisant l'objet d'un suivi côté serveur et indexées par ce cookie.
Donc, quand un client envoie une requête sur le serveur, puis à partir du cookie
l'ID de session est récupéré et qui est utilisé comme un index dans le côté serveur.
Par exemple,
si vous utilisez une base de données côté serveur, cet index sera l'index principal de
cette base de données côté serveur particulière qui suit les sessions. Par
conséquent, des informations supplémentaires sur cette session peuvent être récupérées et
utilisées par votre serveur afin de prendre des décisions sur la façon dont
il traite la demande du client entrant.
Désormais, par défaut, les sessions sont stockées en mémoire sur le site du serveur.
Maintenant, évidemment, cela signifie que si votre serveur est redémarré, votre mémoire
sera effacée et donc toutes les informations de session disparaîtront complètement.
Donc, à la place, de nombreux serveurs
utiliseront une forme de stockage permanent où les informations de session sont suivies.
Le stockage permanent côté serveur pourrait soit être fait
via une sorte de stockage de fichiers.
Ou même tirer parti du fait que vous avez déjà une base de données côté serveur et
que stocker les informations de session côté serveur.
Par exemple, dans votre MongoDB lui-même.
Maintenant, dans l'exercice qui suit, nous allons examiner l'utilisation d'un stockage de fichiers pour
le suivi des informations de session côté serveur.
Un autre aspect auquel vous devez prêter attention est le fait que si vous avez
une implémentation de serveur distribué dans laquelle plusieurs
serveurs agissent comme le serveur pour la maintenance de la requête.
Ensuite, le serveur du distributeur doit pouvoir accéder aux informations de session.
N' importe lequel de ces serveurs doit pouvoir accéder aux informations de session.
Vous aurez donc besoin d'un outil de sessions de distribution côté serveur,
pour vous permettre de prendre en charge plusieurs serveurs répliqués.
Cela est particulièrement utile lorsque nous essayons d'assurer la fiabilité
du fonctionnement du serveur.
Maintenant encore une fois, nous n'aurons pas trop de détails sur ceux de ce
cours particulier, nous compterons sur la compréhension de la façon dont fonctionnent les sessions Express.
Venir spécifiquement à Express et
comment la gestion des sessions est prise en charge dans Express.
Express utilise le middleware express-session qui prend en charge
l'utilisation de sessions dans un serveur Express.
Maintenant, vous installez le middleware express-sessions.
Et dans l'exercice, je vais utiliser la boutique de fichiers
comme un moyen de stocker de façon permanente les informations de session.
Et donc, nous allons également inclure le module de nœud de stockage de fichiers de session qui
nous permet d'utiliser les fichiers côté serveur pour suivre les informations de session.
Nous verrons les détails dans l'exercice qui suit.
Et puis une fois que nous le faisons, votre session elle-même sera configurée avec le nouveau
serveur express en déclarant le middleware ici comme session qui prend
un certain ensemble d'options comme paramètre ici.
Les options incluent le nom de la session, donc nous donnerons l'identifiant de session pour
la session particulière.
Et puis vous fournirez également le secret, une clé secrète qui est utilisée pour
coder le cookie signé qui sera envoyé côté client.
Et puis aussi des informations supplémentaires, y compris saveUnInitialized, qui
sera un indicateur qui est utilisé et aussi un indicateur de resave qui est utilisé.
Nous examinerons certains détails de ces options dans la diapositive suivante.
Donc, toutes ces options sont spécifiées ici.
Et si vous êtes FileStore comme le stockage permanent pour vos sessions,
alors nous le déclarerons également dans les options de session là-bas.
C' est ainsi que nous mettrions en place une session côté serveur express
en utilisant le Middleware de session express.
Et le middleware de session express-, lorsque le client envoie ces informations,
cela sera analysé côté serveur et
cela entraînera l'ajout d'une propriété appelée session à l'objet requête.
Donc, ces informations de session seront accessibles dans l'
objet requête en tant que req.session.
Ainsi, req.session portera des informations supplémentaires sur cette session particulière
pour ce client particulier.
Maintenant, une fois cette session, la requête entrante est analysée par le middleware de session,
la propriété req.session sera ajoutée à l'
objet de message de requête entrant utilisé par express.
Donc, après l'analyse de la session, la propriété de session directe sera disponible et
nous pouvons l'examiner aussi pour vérifier quel client a envoyé cette demande.
Quand ils configurent leur objet de session sur le site du serveur,
comme nous l'avons vu, nous pouvons configurer diverses options pour ce site de serveur.
Le cookie, les options du cookie d'ID de session et la valeur par défaut
du cookie seront comme indiqué ici, qui est le chemin : '/',
HttpOnly : true, secure : false, MaxAge : null.
Donc, ce sera la valeur par défaut du cookie qui sera stocké sur le paquet
et envoyé sur le côté du client en tant que cookie signé.
Et cela serait inclus dans chaque demande entrante du site du client.
Ensuite, le genid est la fonction qui génère l'ID de session.
La valeur par défaut consiste à utiliser l'UUID du serveur lui-même comme ID général.
Ensuite, l'indicateur de resave, s'il est vrai, force une session à être sauvegardée
dans le magasin même si elle n'est pas modifiée par la requête.
Parfois, la requête entrante peut
contenir un besoin de modifier les informations de session côté serveur.
Par conséquent, si les informations de session sont modifiées, elles devront être persistantes.
Si ce n'est pas le cas, alors vous n'avez pas besoin de le persister.
Mais si vous définissez l'indicateur de resave sur true, même si les informations de session sur
le serveur ne sont pas modifiées par la demande du client entrant, il sera toujours régénéré.
L' indicateur suivant que nous avons examiné était SaveUnInitialized.
Si cela est vrai, il va créer une session nouvellement créée sans aucune modification
à enregistrer dans le magasin de sessions.
Maintenant, nous allons définir ceci sur false par défaut, ce qui signifie que nous allons seulement
suivre les sessions qui sont autorisées sur le serveur.
Maintenant, le secret, comme nous le voyons, est la clé secrète qui est utilisée pour signer le cookie,
et le magasin lui-même spécifie l'instance de magasin de session qui est utilisée.
La valeur par défaut est d'utiliser le magasin de mémoire.
Vous pouvez spécifier le magasin de fichiers ou le magasin Mongo pour
stocker ces informations de session, etc.
Donc, une fois que vous spécifiez ces informations pour votre intergiciel
de session express, la session sera correctement configurée et sera donc suivie du côté serveur.
Chaque requête client sera ensuite mappée aux informations de session
côté serveur lorsque la requête client est analysée par le middleware de session express.
Et le req.session sera ajouté dans l'objet requête.
Avec cette compréhension des cookies et des sessions express, passons
à l'exercice où nous allons examiner comment nous allons utiliser les cookies en premier.
Ensuite, nous allons voir comment nous allons utiliser les sessions Express
dans notre application API REST Express sur laquelle nous avons travaillé jusqu'à présent.
[ MUSIQUE]