OVH Cloud OVH Cloud

redirect apres script

15 réponses
Avatar
Josselin
J'ai une page ipn.php sur laquelle est effectuée une redirection après
un paiement Paypal
cette page cointient un script qui met à jour une base de donnée..
pas de problème de ce coté tout fonctionne...
mais une fois ce script executé (de façon transparente pour
l'utilisateur puisqu'il n'y a rien à afficher) comment faire pour
automatiquement rediriger vers lune autre page... ?
le header redirect ne peut être mis qu'en début de page .... pas à la fin
j'ai déjà fiat des redirections, mais il y avait une form est une
action de l'utilisateur qui proqovuait un refresh....
pas dans ce cas de figure :-((

pni.php
<?
script de mise à jour de la base de données à partir des données _POST
de Paypal
...
(aucun affichage, aucune intervention de l'utilisateur)
..
redirection automatique vers une page ? -> index.php
?>

5 réponses

1 2
Avatar
John Gallet
Bonjour,

mais une fois ce script executé (de façon transparente pour
l'utilisateur puisqu'il n'y a rien à afficher) comment faire pour
automatiquement rediriger vers lune autre page... ?
Si le besoin est réel, on peut rediriger par un header(Location) : il

suffit d'activer l'output buffering pour être sûr qu'on espace ou un
retour chariot perdu dans un fichier appelé par include/require n'a pas
déjà provoqué l'envoi des headers.
Je n'ai pas encore été convaincu qu'un besoin réel puisse exister mais
bon. Dans cette logique (rediriger totalement en fin de script
"atomique") ce n'est pas grave.

le header redirect ne peut être mis qu'en début de page .... pas à la fin
Si, si. N'importe où du moment qu'aucune sortie html (qui provoque,

selon le mécanisme de PHP, l'envoi des headers) n'a eut lieu.

j'ai déjà fiat des redirections, mais il y avait une form est une action
de l'utilisateur qui proqovuait un refresh....
Et alors ? si tu as un blaireau qui décide d'envoyer en boucle les mêmes

données à ton script, tu gères comment ?

En revanche, ce qu'il ne faut PAS faire c'est la chose suivante :
<?php
// valider.php
// vérification des arguments, est-ce que tout est bon
// si oui : header Location traiter.php

Non seulement on fait faire un aller-retour inutile aux données, mais en
plus, n'importe qui peut appeler traiter.php en direct sans passer par
valider.php avec en plus écriture des données (potentiellement
confidentielles) dans les logs.

a++;
JG

Avatar
ftc
Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.



C'est complètement stupide. Faire un redirect après un POST est au
contraire une très bonne pratique, qui évite les problèmes de
resoumission du formulaire si l'utilisateur rafraichit la page


Pas dans tous les cas, mon Firefox ressoumet allègrement le formulaire
lorsque je reviens en arrière.


Si votre banque suivait votre conseil, par exemple, et revenait à la
situation de votre compte après un virement effectué sans faire de
redirect, et si vous rafraichissiez la page, vous vous prendriez un
avertissement de la part de votre navigateur (incompréhensible pour la
plupart des utilisateurs), et vous réeffectueriez le virement.


Il y a quand même des solutions un peu plus robustes pour éviter ce
genre de cas.



Avatar
John Gallet
Re,

Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.


C'est pas moi qui dirait le contraire, mais dans le cas décrit ici,
c'est un moindre mal : il n'y a pas de risques particuliers.

JG

Avatar
John Gallet
Bonjour,


Faire un redirect après un POST
Après, une fois que complètement traité, ça me parait toujours idiot

(autant que vous ne pas le faire vous parait stupide) mais au moins ce
n'est pas dangereux en soit.

Si votre banque suivait votre conseil, par exemple, et revenait à la
situation de votre compte après un virement effectué sans faire de
redirect, et si vous rafraichissiez la page, vous vous prendriez un
avertissement de la part de votre navigateur (incompréhensible pour la
plupart des utilisateurs), et vous réeffectueriez le virement.


Sauf si on code intelligement et qu'on demande validation de l'envie de
faire deux fois un virement du même montant du même compte source vers
le même compte cible dans la même session. Ce qui devrait de toutes
façons être fait pour éviter les erreurs.

De plus, au contraire de ce que la FAQ indique, un redirect n'a pas
grand chose à voir avec un meta refresh, qui doit toujours être évité,
parce qu'il casse le bouton back du navigateur
Lire à ce propos http://www.w3.org/QA/Tips/reback ou
http://en.wikipedia.org/wiki/META_refresh


Faut apprendre à lire hein :
<CITE>
Remarque : il y a des différences entre les header http et les balises
meta mais le trajet de l'information est le même. Plus d'informations
sur : http://www.w3.org/QA/Tips/reback
</CITE>

JG

Avatar
Patrick Mevzek
De toute façon, quel que soit le code, 302 ou 307, le résultat est le
même: c'est une bonne pratique de faire un redirect après un post,


Non.

présentée à l'uilisateur. Vous pouvez rester dans votre tour d'ivoire si
vous le désirez, il n'empêche que c'est un pattern qui est préconisé par
...


On ne saura pas par qui. Mais par contre, il y a plein de choses
préconisées par des gens qui n'y connaissent rien. Ce n'est pas parce
qu'une foule crie quelque chose qu'elle a raison. Et en particulier
l'article que vous avez cité est tellement rempli de bêtise que cela le
décridibilise suffisamment pour ne considérer aucune des pratiques
présentées comme bonnes.

Mauvais code applicatif. Il y a des solutions pour gérer le
rechargement.

Oui. Et la meilleure, c'est d'utiliser un redirect après un post.



Absolument pas.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>


1 2