La vérification du nom d'utilisateur de connexion est généralement publiée ensemble sur le serveur.
La méthode get exposera les paramètres à la fin du lien, mais le navigateur lui-même n'a aucun cryptage. Si vous le cryptez, vous devez l'ajuster vous-même.
Pour certaines valeurs de formulaire, qu'elles soient valides et non vides, etc., il devrait y avoir une invite avant la soumission pour améliorer l'expérience utilisateur.
Les deux doivent être faits. Le front-end est pour l'expérience utilisateur (connaître le problème avant de faire une demande), et le back-end est pour la sécurité.
Pour les services de niveau entreprise, utilisez https au lieu du texte brut.
Supposons que le nom d'utilisateur doit comporter plus de 3 chiffres ; le mot de passe doit comporter de 6 à 32 chiffres ; le code de vérification doit comporter 4 chiffres ; Lorsque vous cliquez pour vous connecter, il est détecté que la longueur du nom d'utilisateur est ; supérieur à 3, la longueur du mot de passe est de 6 à 32 et la longueur du code de vérification est de 4 ; En descendant, pas par alerte 2. Publier les paramètres sur le serveur, nommer le code pwd 3, le serveur. reçoit les paramètres 4. Vérifiez si la longueur est égale à 4, non égale à 4, retournez La longueur du code de vérification est anormale 5. Récupérez le code de la session et voyez s'il est cohérent avec le code du paramètre. erreur 6. Vérifiez la longueur du nom d'utilisateur et la longueur du mot de passe S'ils sont incorrects, renvoyez l'erreur 7. Si vous devez corriger le cryptage pwd Sélectionnez name=name, pwd=pwd dans la base de données. , si oui, l'utilisateur sera renvoyé, sinon, 0 sera renvoyé
GET affiche directement les données dans l'URL ; POST est "caché", l'URL n'est pas visible, mais elle peut être vue à l'aide des outils de développement du navigateur Peu importe lequel des éléments ci-dessus, "les pirates informatiques ; " En capturant des paquets, vous pouvez également obtenir les données en clair pendant la transmission des données ; vous pouvez même falsifier/détourner le contenu, puis le transmettre au serveur, ou directement prétendre être le serveur et vous renvoyer de fausses informations. Si vous utilisez HTTPS, les données seront d'abord cryptées lors de la transmission, ce qui est relativement sûr. Quant à la vérification des paramètres, elle doit être effectuée à la fois sur le front-end et sur le back-end, car la vérification JS sur le front-end peut facilement être contournée.
La vérification du nom d'utilisateur de connexion est généralement publiée ensemble sur le serveur.
La méthode get exposera les paramètres à la fin du lien, mais le navigateur lui-même n'a aucun cryptage. Si vous le cryptez, vous devez l'ajuster vous-même.
Pour certaines valeurs de formulaire, qu'elles soient valides et non vides, etc., il devrait y avoir une invite avant la soumission pour améliorer l'expérience utilisateur.
Les deux doivent être faits. Le front-end est pour l'expérience utilisateur (connaître le problème avant de faire une demande), et le back-end est pour la sécurité.
Pour les services de niveau entreprise, utilisez https au lieu du texte brut.
Supposons que le nom d'utilisateur doit comporter plus de 3 chiffres ; le mot de passe doit comporter de 6 à 32 chiffres ; le code de vérification doit comporter 4 chiffres ;
Lorsque vous cliquez pour vous connecter, il est détecté que la longueur du nom d'utilisateur est ; supérieur à 3, la longueur du mot de passe est de 6 à 32 et la longueur du code de vérification est de 4 ; En descendant, pas par alerte
2. Publier les paramètres sur le serveur, nommer le code pwd
3, le serveur. reçoit les paramètres
4. Vérifiez si la longueur est égale à 4, non égale à 4, retournez La longueur du code de vérification est anormale
5. Récupérez le code de la session et voyez s'il est cohérent avec le code du paramètre. erreur
6. Vérifiez la longueur du nom d'utilisateur et la longueur du mot de passe S'ils sont incorrects, renvoyez l'erreur
7. Si vous devez corriger le cryptage pwd
Sélectionnez name=name, pwd=pwd dans la base de données. , si oui, l'utilisateur sera renvoyé, sinon, 0 sera renvoyé
GET affiche directement les données dans l'URL ;
POST est "caché", l'URL n'est pas visible, mais elle peut être vue à l'aide des outils de développement du navigateur
Peu importe lequel des éléments ci-dessus, "les pirates informatiques ; " En capturant des paquets, vous pouvez également obtenir les données en clair pendant la transmission des données ; vous pouvez même falsifier/détourner le contenu, puis le transmettre au serveur, ou directement prétendre être le serveur et vous renvoyer de fausses informations.
Si vous utilisez HTTPS, les données seront d'abord cryptées lors de la transmission, ce qui est relativement sûr.
Quant à la vérification des paramètres, elle doit être effectuée à la fois sur le front-end et sur le back-end, car la vérification JS sur le front-end peut facilement être contournée.
Get sera exposé, mais pas la publication. Soyez prudent