Si le front-end et le back-end sont séparés, le serveur ne pourra-t-il pas définir de cookies ?
erreur. La séparation du front-end et du back-end ne signifie pas que le serveur ne peut pas définir de cookies. Dans une architecture où le front-end et le back-end sont séparés, le front-end communique généralement avec le back-end via des appels API au lieu de restituer directement la page HTML générée par le back-end. Cela empêche le serveur de définir des cookies dans la réponse comme les applications de rendu traditionnelles côté serveur.
Cependant, le serveur peut toujours définir le cookie et l'envoyer au client via l'en-tête Set-Cookie dans la réponse. Dans une architecture de séparation front-end et back-end, cela est généralement effectué après une connexion ou une authentification réussie, afin que le serveur puisse stocker le jeton d'authentification ou les informations de session dans un cookie et les vérifier lors des demandes ultérieures.
L'application frontale (généralement JavaScript) peut lire et traiter ces cookies à partir de la réponse, puis les renvoyer au serveur dans le cadre des en-têtes de requête dans les requêtes API ultérieures. Cela permet au serveur d'utiliser le cookie lors de demandes ultérieures pour authentifier l'utilisateur ou fournir d'autres fonctionnalités liées à la session.
Pour résumer, bien que l'architecture de séparation front-end et back-end modifie la façon dont le serveur définit les cookies, le serveur peut toujours définir des cookies dans les réponses et gérer l'authentification des sessions et des utilisateurs via des requêtes et des réponses API.
Le serveur de séparation front-end et back-end peut également définir des cookies pour le navigateur.
Tout d'abord, vous devez comprendre comment le serveur définit les cookies pour le navigateur.
Dans le backend proportionnel, en prenant php comme exemple, setcookie() est appelé ;
Mais ce n'est qu'une apparence. Le mécanisme de paramétrage spécifique consiste à ajouter des informations set-cookie à l'en-tête renvoyé au navigateur, par exemple :
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMTLe navigateur définit les cookies en fonction deen-tête de réponse, cela n'a donc rien à voir avec la séparation du front-end et du back-end.
Situation inter-domaines entre le serveur front-end et le serveur back-end
Lorsqu'il existe une situation inter-domaines entre le serveur frontal et le serveur back-end, la configuration des cookies sera restreinte. Cross-domain signifie que dans le navigateur, le domaine de l'application frontale est différent du domaine du serveur back-end.
Dans les situations d'origine croisée, par défaut les navigateurs empêchent la définition de cookies inter-domaines via l'en-tête Set-Cookie de la réponse. Il s’agit de protéger la confidentialité et la sécurité des utilisateurs. Les navigateurs suivent la politique de même origine, qui exige qu'une page Web ne puisse accéder qu'aux ressources de la même origine.
Il existe cependant des moyens de contourner cette limitation :
CORS (Cross-Origin Resource Sharing) : le serveur principal peut autoriser des requêtes inter-domaines spécifiques en définissant les en-têtes de réponse CORS appropriés, notamment en autorisant le transport de cookies. Par exemple, vous pouvez autoriser les requêtes inter-domaines à transporter des cookies en définissant l'en-tête « Access-Control-Allow-Origin » sur le domaine du serveur frontal et en définissant l'en-tête « Access-Control-Allow-Credentials » sur "vrai".
Serveur proxy : le serveur frontal peut transférer les requêtes via le serveur proxy, envoyer des requêtes inter-domaines au serveur principal et définir des cookies sur le serveur proxy. De cette manière, la communication entre le serveur frontal et le serveur back-end ne sera pas limitée par la politique de même origine du navigateur.
Il convient de noter que s'il existe une situation inter-domaines, la sécurité et la confidentialité doivent être prises en compte lors de la configuration des cookies. Assurez-vous que les requêtes inter-domaines ne peuvent contenir des cookies que lorsque cela est nécessaire et que les requêtes sont correctement vérifiées et autorisées pour éviter d'éventuelles vulnérabilités de sécurité.
Comment déterminer le cross-domain
Dans le développement front-end, déterminer si une requête inter-domaines repose généralement sur les trois facteurs suivants : le protocole, le nom de domaine et le numéro de port. Si l’un des facteurs est différent, il s’agit d’une demande inter-domaines.
Par exemple, en supposant que l'application frontale s'exécute sur http://a.log.com, voici quelques exemples pour déterminer si une requête inter-domaines est :
Demande inter-protocole : si l'application frontale s'exécute via http://a.log.com, mais que l'URL demandée commence par https://, par exemple comme https ://b.log.com/api/data, est considérée comme une requête inter-domaines car les protocoles sont différents.
Demande inter-domaines : si l'application frontale s'exécute via http://a.log.com, mais que l'URL demandée commence par http://b. log.com Commençant par /api/data, ou simplement en utilisant un autre nom de domaine de deuxième niveau, tel que http://subdomain.log.com/api/data, cela est considéré comme une requête inter-domaines.
Demande cross-port : si l'application frontale s'exécute via http://a.log.com:8000, mais que l'URL demandée commence par http:// a.log .com:9000/api/data, ou si un numéro de port différent est utilisé, cela est considéré comme une requête inter-domaines.
Il convient de noter que la politique de même origine dans le navigateur restreindra l'accès aux requêtes inter-domaines pour des raisons de sécurité. L'accès aux requêtes inter-domaines peut être autorisé en utilisant CORS (Cross-Origin Resource Sharing) ou d'autres solutions inter-domaines.
Le serveur frontal transmet les requêtes via un serveur proxy et gère les requêtes inter-domaines.
Configurer les paramètres du serveur proxy sur le serveur frontal : le serveur frontal doit configurer un serveur proxy pour recevoir les requêtes inter-domaines et les transmettre au serveur principal. Ceci peut être réalisé en utilisant un logiciel de serveur proxy courant (tel que Nginx, Apache) ou un script de serveur proxy personnalisé.
L'application frontale envoie une demande au serveur proxy : lorsqu'une application frontale envoie une demande inter-domaines, elle envoie la demande à l'adresse du serveur proxy sur le serveur frontal au lieu de directement au serveur principal. Par exemple, une application frontale envoie une requête à http://frontend-server/proxy.
Le serveur proxy transmet la demande au serveur back-end : une fois que le serveur proxy a reçu la demande de l'application frontale, il la transmet à l'adresse correspondante du serveur back-end. Par exemple, le serveur proxy transmet les requêtes à http://backend-server/api.
Le serveur backend traite la demande et définit le cookie : une fois que le serveur backend a reçu la demande transmise par le serveur proxy, il la traite en conséquence et définit le cookie dans la réponse (si nécessaire). Le serveur principal peut gérer la demande en fonction de la logique métier et inclure l'en-tête Set-Cookie dans la réponse pour définir le cookie.
Le serveur proxy renvoie la réponse à l'application frontale : une fois que le serveur principal a traité la demande, il renvoie la réponse au serveur proxy.
Le serveur proxy renvoie la réponse à l'application frontale : une fois que le serveur proxy a reçu la réponse du serveur principal, il la renvoie à l'application frontale. L'application frontale peut le gérer en conséquence après avoir reçu la réponse.
En utilisant un serveur proxy, les applications frontales peuvent contourner les restrictions de politique de même origine du navigateur et permettre une communication interdomaine entre les serveurs frontaux et principaux, tout en autorisant la configuration et le traitement des cookies. Les détails spécifiques de mise en œuvre et les méthodes de configuration peuvent varier en fonction du logiciel de serveur proxy sélectionné ou des scripts personnalisés, et nécessitent donc une configuration et un développement correspondants en fonction de la situation spécifique.
Restrictions liées aux règles de même origineExplication
En fait, une même politique d'origine est principalement un mécanisme de sécurité mis en œuvre par les navigateurs pour restreindre l'accès des scripts clients entre différentes sources (protocole, nom de domaine, port). La politique de même origine restreint l'accès des applications frontales du navigateur aux serveurs d'origines différentes, mais dans la communication entre serveurs, la politique de même origine ne s'applique pas.
Lors de la communication entre serveurs, ils ne sont pas limités par la politique de même origine du navigateur. La communication entre les serveurs peut librement effectuer des requêtes et des réponses inter-domaines et partager des données, car les serveurs peuvent accéder directement aux ressources sans passer par les restrictions de sécurité du navigateur.
Par conséquent, si vous utilisez un serveur proxy dans une application frontale pour transférer les requêtes vers un serveur principal, la communication entre le serveur proxy et le serveur principal n'est pas limitée par la stratégie de même origine du navigateur. Cela permet la configuration et la gestion des cookies sur le serveur proxy, ainsi que la gestion des demandes et réponses inter-domaines.