Bonjour,

Ma question est la suivante, en utilisant la méthode POST, lorsque l'on souhaite revenir en arriére, le navigateur rappel que avec un GROS message.



Les données post renvoyées , je gère déjà (INSERT, UPDATE, DELETE etc...).

Ce que je voudrais, c'est que l'utilisateur ne voit plus ce message pénible.

J'ai essayé avec header('Cache-Control:max-age=0') entre autre mais ça ne me convient pas.
Ie affiche souvent "page expirée" (encore pire) avec ce que j'ai essayé.

je souhaite que le retour de page se fasse exactement comme n'importe quel changement de page avec les requêtes rejouées.

L'un d'entre vous à t'il la solution (qui existe pourtant car des forums par exemple n'ont pas ce message).

cordialement Alf

Tu peux tout simplement faire un header sur la page en cours. Si ta page se nomme page1.php, à la fin du traitement de tes données tu peux faire

header('Location:page1.php');

Y'a d'autres variantes mais le principe est là

Malheureusement ça ne fonctionne pas dans mon contexte (ou alors j'ai mal interprété la réponse).

J'ai 2 pages auth.php et index.php (qui est la page usuelle une fois logée, fonctionne avec les "include" qui conviennent selon les actions de l'utilisateur).

Si index.php et rechargé sans les bons arguments ou sans l'existence de session ou à la moindre incohérence des données POST reçues -> renvoi à la page auth.php (log et fermeture de session).

Le header() à donc pour simple effet de me renvoyer à l'authentification et clore ma session.

Ce que je trouve le plus étonnant c'est que GET ne génère pas ce type d'alerte il me semble (comme si l'utilisateur grand public pouvait savoir qu'il y a un risque de re-jeux des données).

Si t'es calé en JavaScript, tu peux faire une authentification "en live" avec AJAX, là, tu n'auras pas de cette boite normalement, puis tu gagnes en design aussi

il y a untruc que je ne comprend pas ce type de message c'est a l'utilisateur de le gerer non a toi.
si il trouve sa genant il configure son nav. pour ne plus l'avoir donc la excuse moi l'expression mais c'est chier dans la colle pour que sa seche plus vite...ce que tu veux faire.

@chrislabricole
Pour Ajax je débute juste, mais je ne vois pas vraiment comment cela peut régler mon problème, qui n'est pas un problème d'authentification.

@hakazizi
J'ai envie de rendre agreable l'usage de ce site, la plus part des applis web évoluées ne l'affichent pas (hakazizi, joomla, phpbb) supposer que les gens savent comment le faire est tres optimiste, je ne le sais pas moi même (en même temps j'ai pas cherché).

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

@chrislabricole
Pour Ajax je débute juste, mais je ne vois pas vraiment comment cela peut régler mon problème, qui n'est pas un problème d'authentification.

ben tout simplement quand tu cliques sur le bouton "se connecter" par exemple le fichier php qui est liée à AJAX va créer les sessions pour que l'utilisateur soit authentifié, puis fait recharger la page, avec ça, tu n'auras plus le message parce-que la page est appelée "en transparence"...

hop hop hop... on se calme avec ajax à toutes les sauces ou la configuration du navigateur sur les postes client !!

D'abord comprendre le problème : Pour ouvrir la page spécifiée dans l'url, l'utilisateur a envoyé des données au serveur via la méthode POST. Afin de ré-accéder à cette même page (après un "retour" ou une "actualisation") le navigateur doit renvoyer ces données et en informe l'utilisateur. En effet, lorsqu'on vient de payer un truc en ligne, on a pas forcément envie de se voir débité 2 fois parce qu'on a actualisé la page. Du coup le navigateur demande confirmation, à savoir, l'utilisateur veut-il renvoyer les données ?

En GET, lorsque tu actualises une page, toutes les données sont déjà spécifiées dans l'url. Tu demandes donc juste l'ouverture d'une adresse spécifique en indiquant au préalable dans son chemin les données nécessaires à son affichage (tu es donc sensé les voir, les connaitre et les maitriser, contrairement à celles transmises par POST)

Ca, c'est le comportement normal de tout navigateur digne de ce nom

Il existe plusieurs solutions pour éviter cela, mais la plus commune et la plus propre - sans se lancer dans des développements à outrance (à coup d'ajax) ou des demandes de paramétrages spécifiques à ses visiteurs - c'est celle d'AB, ou plus exactement le pattern "PRG" : "Post-Redirect-Get"

L'idée est qu'à la fin du traitement des données soumises en POST, le serveur redirige l'utilisateur en GET avec un header. Cette redirection étant transparente pour le navigateur (et l'utilisateur), l'actualisation de la page par l'utilisateur a pour effet de recharger la nouvelle page ouverte en GET (au lieu d'une page ouverte en post) et la fonction retour du navigateur le renvoi sur le formulaire, avant l'envoi des données en POST. Ainsi, à aucun moment l'utilisateur ne renvoi de données en POST, et le navigateur ne lui demande pas de confirmation.

Dans ton cas, il faut donc après l'autentification de ton visiteur (et enregistrement en session des données qui vont bien), que tu le rediriges automatiquement avec un header vers ta page index.php (en spécifiant éventuellement en GET les paramètres nécessaires à l'ouverture de la page) et le tour est joué

@chrislabricole
si je comprend bien tu veux dire que les données envoyées par POST via la méthode open de l'objet Ajax (je viens juste d'acheter un bouquin ) ne subissent pas ce problème, puis que techniquement parlant ... on ne change pas de page ... on rafraichie juste une partie de celle existante ?

@ryle
Merci de ta réponse très complète (et merci à AB aussi).

Du coup, je suis assez déçu, parce que je ne vois pas la différence avec l'usage systématique de GET.

C'est cependant une façon simple d'éviter la double soumission que je ne connaissait pas (problème que j'ai traité avec une solution plus complexe en base de donnée).

Mon choix initial de POST est fait lié à la sécurité, cacher les données envoyées par l'utilisateur, éviter par exemple qu'ils envoient l'url à un ami avec des infos dedans, y compris login et mot de passe par inadvertance et que ceux-ci soient lisible dans l'historique.

La sécurité est l'objectif premier du développement de mon appli depuis 0 (plutôt que le choix d'un CMS) la suppression de se message est donc plus un luxe qu'un impératif.

En fait il y a peut être des solutions avec GET que je n'ai pas envisagées ?
Un genre de masquage/réécriture/cryptage de l'url.

@chrislabricole
si je comprend bien tu veux dire que les données envoyées par POST via la méthode open de l'objet Ajax (je viens juste d'acheter un bouquin ) ne subissent pas ce problème, puis que techniquement parlant ... on ne change pas de page ... on rafraichie juste une partie de celle existante ?

Oui c'est ça, et donc la page appelée par AJAX, c'est une page qui va créer les sessions (ou non !) pour que l'utilisateur soit authentifié...

Hey ,

Et un utilisateur qui est aveugle et qui a une planche braille fait comment pour se connecter sur ton site si tu utilises Ajax ?

HTML 5 va proposer des choses intéressantes pour le couplage avec Ajax, et devrait améliorer un peu l'accessibilité. Ça reste quand même très dur actuellement. AB et Ryle ont donné une solution fonctionnelle, utilisée, et qui a fait ces preuves. C'est celle-là que Alf doit utiliser, car la plus simple et la plus propre actuellement.

oui, c'est vrais ça l'accessibilité est importante pour mon site (outre qu'Ajax m'obligerais à repenser mon coeur d'appli).

Je pense qu'a défaut de trouver une solution qui cache les données transmises à l'utilisateur lambda par défaut je ferais avec le popup de sécurité.

Comme l'appli gére de l'argent (pas directement sur un compte mais tout de même) j'utiliserais peut être POST pour l'authentification et GET pour le reste en attendant de trouver mieux.

Bonjour,
Puis-je permettre de remettre cette discution en débat ?
Voilà, je voudrais savoir comment faire pour rediriger les variables reçues en POST vers des variables GET c-à-d, faire le fameux PRG ?
Merci d'avance