Pourquoi utiliser Post/Redirect/Get (PRG) pour empêcher la nouvelle soumission des données ?

Comprendre le modèle « Post/Redirect/Get » intrinsèquement déroutant

Malgré les nombreux aperçus du modèle « post/redirect/get », la compréhension de ses subtilités peut rester insaisissable. Approfondissons pour élucider ce concept.

Post : Envoi de données sensibles

Dans certains cas, les applications exigent que les utilisateurs soumettent des informations sensibles, telles que des mots de passe ou des numéros de carte de crédit. Grâce à la méthode HTTP POST, ces valeurs sont intégrées de manière sécurisée dans le corps de la requête et ne sont pas exposées dans l'URL.

Redirection : éviter plusieurs publications

Cependant, après le traitement POST, renvoyer immédiatement un La page de réponse peut entraîner une nouvelle soumission accidentelle si les utilisateurs actualisent la page. Pour éviter cela, une redirection est émise vers une nouvelle URL. Cette nouvelle URL ne contient plus la charge utile POST, ce qui la protège des soumissions répétées.

Obtenir : récupération des résultats

Enfin, l'utilisateur atterrit sur l'URL GET, qui affiche généralement les résultats du POST. opération. Cette séparation de la saisie des données (POST) de l'affichage des données (GET) garantit l'intégrité des données et une expérience utilisateur plus propre.

Visualisation illustrative

Considérez le schéma suivant :

[Image : "Le problème" - Les données POST entrent dans un entonnoir, mais leur sortie déclenche un nouveau POST. "La solution" - Les données POST entrent dans un entonnoir, qui redirige vers une page GET]

En comprenant le problème de la re-soumission et le rôle de la redirection pour l'atténuer, le modèle "post/redirect/get" devient plus intuitif.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!