阿神2017-04-22 09:01:18
Avis personnel, à titre indicatif seulement.
Utiliser le débogage et le code est un bon moyen d'apprendre un framework, mais le principe est que vous compreniez les connaissances de base. Si vous n'êtes pas familier avec le protocole http lui-même, alors regarder le framework qui l'implémente, c'est comme lire une Bible.
Par exemple, cette vérification d'identité.
Tout d'abord, vous devez savoir que http est dans la plupart des cas une connexion courte. Le client (le navigateur dans la plupart des cas) établit une connexion avec le serveur http, envoie des données, puis récupère les données renvoyées par le serveur, puis les envoie. la connexion est déconnectée.
Deuxièmement, vous devez savoir que les données dans la communication http sont divisées en requête (Request) et réponse (Response). La requête est envoyée par le client (au serveur) et la réponse est renvoyée par le serveur au client. La demande et la réponse sont divisées en en-tête et réponse (Content), l'en-tête est obligatoire et le contenu peut être vide.
Après avoir connu les deux points ci-dessus, examinons la vérification d'identité.
La vérification de l'identité est grossièrement divisée en deux processus :
1. Connexion utilisateur ;
2. Lorsqu'un utilisateur accède à d'autres ressources, vous obtenez l'identité de l'utilisateur et déterminez s'il peut accéder à cette ressource
;
Comme mentionné ci-dessus, http est une connexion courte dans la plupart des cas, et le scénario ci-dessus est une connexion courte.
Les utilisateurs se connectent et accèdent à d'autres ressources, qui sont évidemment deux connexions.
Ensuite, le serveur ne peut pas déterminer que les deux connexions proviennent de vous, alors comment obtenir l'identité de l'utilisateur lorsque vous vous connectez à la ressource pour la deuxième fois ?
Afin de résoudre ce problème, le protocole http prévoit des cookies.
Lors de la première connexion - lors du traitement de la connexion de l'utilisateur, si l'utilisateur se connecte avec succès, l'en-tête de la réponse du serveur (Response) contient l'en-tête Set-Cookie, qui contient les informations de l'utilisateur, indiquant que le client enregistre certains cookies. et stipule dans quelles circonstances (voir les dispositions relatives aux cookies pour plus de détails) le client doit renvoyer ces cookies au client.
Lors de la deuxième connexion - lors de l'accès aux ressources, parce que les conditions d'envoi des cookies sont remplies, le client mettra le cookie dans l'en-tête de la requête (Request) en tant qu'en-tête Cookie. De cette manière, le serveur obtient le cookie en analysant l'en-tête de la requête, et en obtient également les informations sur l'utilisateur.
Il s'agit du processus de mise en œuvre sous-jacent d'une vérification d'identité.
Parmi eux, le navigateur gère le Set-Cookie dans l'en-tête de réponse, enregistre le cookie, place le cookie dans l'en-tête de la requête et l'envoie au serveur lorsque les conditions sont remplies.
Le placement de Set-Cookie dans l'en-tête de réponse et la lecture des informations sur les cookies à partir de l'en-tête de demande peuvent être implémentés par le framework que vous utilisez.
////////// Ajouter la réponse à la réponse //////////
Après que le questionneur ait répondu, j'ai ajouté le contenu discuté avec le questionneur dans la réponse.
Ce que j'ai mentionné ci-dessus est la condition préalable à la compréhension du cadre. Autrement dit, vous devez d’abord comprendre ce que le framework a fait pour vous, puis examiner comment le framework fait ces choses.
Voici le contenu de la discussion, j'étais paresseux et je l'ai copié-collé directement :
Permettez-moi de parler de ma compréhension générale : le framework Web est responsable du décodage des requêtes ainsi que de l'encodage et de l'encapsulation des réponses. Lorsque les développeurs ont besoin d’écrire une logique, ils n’ont besoin que d’obtenir des paramètres et de renvoyer des données. La manière dont les paramètres sont extraits de la requête et la manière dont les résultats renvoyés sont codés dans les réponses sont toutes effectuées par le framework.
Par conséquent, de manière générale, vous pouvez définir des points d'arrêt au début et à la fin de la logique que vous écrivez, puis suivre le traitement à l'intérieur du framework.
Tout d'abord, définissez un point d'arrêt à la fin. C'est relativement simple, car une fois votre traitement logique terminé et les données renvoyées, elles sont transmises au framework pour traitement. À ce stade, vous pouvez suivre l'intérieur du code du framework. grâce au traçage en une seule étape et surveillez votre retour étape par étape. Les données sont traitées par le framework.
L'autre consiste à définir un point d'arrêt au début. À ce stade, la partie traitement du framework a effectivement été exécutée, mais les outils de débogage généraux peuvent voir la pile d'appels. Vous pouvez utiliser la pile d'appels pour voir quel code le framework a exécuté auparavant. exécutez votre code logique, recherchez ensuite le code dans lequel la requête vient d'arriver, définissez un point d'arrêt ici, renvoyez la requête, puis suivez-la étape par étape.
Après avoir suivi les codes de début et de fin, vous comprendrez déjà le flux de traitement de l'ensemble du framework.
répondre
0
