retour page precedente
docanski
La commande
<a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a>
est l'équivalent de
<a href="javascript:history.go(-1)">Retour</a>
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
fiable.
Est-ce vrai ? Mes essais avec EasyPHP me donnent systématiquement la
réponse :
"Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php
echo '$HTTP_REFERER' ?>"
IL y est pourtant, au même niveau que la page appelante.
Existe-t'il une variante et, question subsidiaire, un équivalent à
<a href="javascript:history.go(-x)">Retour</a> ?
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Fredchou
Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
--
Fredchou
mailto:fred...@nospam.free.fr.invalid
Mihamina Rakotomandimby (R12y)
> mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
> fiable.
D'apres moi, elle n'est pas fiable dans la mesure ou HTTP_REFERRER est lié à
HTTP.
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un
serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
Je ne pense pas que dans ces conditions HTTP_xxx soit renseigné.
Olivier Miakinen
>
> La commande
> <a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a>
> est l'équivalent de
> <a href="javascript:history.go(-1)">Retour</a>
Bof.
Cela suppose que :
1) HTTP_REFERER est transmis par le navigateur ;
2) register_globals est à On (mais sinon on peut utiliser les variables
superglobales) ;
3) JavaScript est actif sur le navigateur ;
4) On arrive sur la page via un lien et pas, par exemple, via un autre
history.go(-1), ni une URL saisie par l'utilisateur.
> mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
> fiable.
Cf. points 1, 2 et 4 ci-dessus.
> Existe-t'il une variante et, question subsidiaire, un équivalent à
> <a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour, voire la
possibilité de revenir de plus d'un niveau dans l'historique (et même
de repartir en avant quand on est revenu en arrière). Ceci est mille
fois préférable à un lien généré en JavaScript, et dix mille fois
préférable à un lien généré à partir du HTTP_REFERER.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
vers la page qui est « logiquement » avant ou après la page en cours,
indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
docanski
Fredchou nous narre ce qui suit en ce 21/05/2007 17:46 :
> Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ça n'y change rien.
Ce qui est curieux, c'est que même ôtés, le passage du curseur sur le
lien de retour affiche la commande *avec* ces guillemets simples dans la
barre d'état.
docanski
> Cela suppose que :
> 1) HTTP_REFERER est transmis par le navigateur ;
> 2) register_globals est à On (mais sinon on peut utiliser les variables
> superglobales) ;
> 3) JavaScript est actif sur le navigateur ;
> 4) On arrive sur la page via un lien et pas, par exemple, via un autre
> history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
>> Existe-t'il une variante et, question subsidiaire, un équivalent à
>> <a href="javascript:history.go(-x)">Retour</a> ?
>
> Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et
en plein écran (bornes d'informations à disposition du public), en
éliminant donc toute possibilité d'utiliser les outils du navigateur,
pour des raisons de sécurité.
> Ceci est mille
> fois préférable à un lien généré en JavaScript,
C'est pourquoi je tente d'éliminer JS au profit de PHP.
> et dix mille fois
> préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie.
La solution me paraissait pourtant universelle, du moins pour les
navigateurs graphiques.
> Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
> vers la page qui est « logiquement » avant ou après la page en cours,
> indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours
à ce genre de commande est dicté par le fait que ces pages peuvent être
appelées à partir de 5 menus différents + des liens internes existants
dans d'autres pages. Une barre de navigation est ainsi, au moins pour
cette dernière raison, impossible à envisager.
Je suis donc preneur de toute autre solution mais n'avais trouvé que
celle-là dans la doc.
Olivier Miakinen
>> <a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a>
>
> Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ah oui, aussi. Je n'avais même pas vu ça. ;-)
docanski
17:46 :
> Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un
> serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
En fait j'essaye les deux. Lorsque j'ai le message d'erreur précédemment
cité, il s'agit bien d'une url retournée en "file://" mais j'utilise
également le serveur de EasyPHP pour les essais. Dans ce cas l'adresse
est bien http://127.0.0.1/etc ...
Le problème est qu'alors j'ai le plus souvent l'erreur 403 signalant :
"You don't have permission to access /Chantier PHP/< on this server."
Ni dans la doc, ni dans la FAQ du logiciel je ne trouve de réponse à ce
problème :-(
Peut-être est-ce un problème de paramétrage mais je n'ai pas réussi à
mettre la main sur un tuto capable de me renseigner.
Florian Sinatra
> "Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php
> echo '$HTTP_REFERER' ?>"
Tu es sûr d'avoir lancé ton serveur Apache ?
docanski
> Tu es sûr d'avoir lancé ton serveur Apache ?
Ben oui : à l'ouverture du logiciel, la fenêtre signale bien le
démarrage d'Apache et de MySQL (feux au vert) avec la confirmation
"démarrage des serveurs".
Olivier Miakinen
>
>> Cela suppose que :
>> 1) HTTP_REFERER est transmis par le navigateur ;
>> 2) register_globals est à On (mais sinon on peut utiliser les variables
>> superglobales) ;
>> 3) JavaScript est actif sur le navigateur ;
>> 4) On arrive sur la page via un lien et pas, par exemple, via un autre
>> history.go(-1), ni une URL saisie par l'utilisateur.
>
> Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
RTFM ;-)
Ça doit être la question qui est revenue le plus souvent toutes
catégories confondues depuis que la valeur par défaut pour
register_globals est passé de Off à On dans la 4.2.0.
Voir http://www.php.net/register_globals
>> Tout navigateur qui se respecte offre un bouton Retour,
>
> Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et
> en plein écran (bornes d'informations à disposition du public), en
> éliminant donc toute possibilité d'utiliser les outils du navigateur,
> pour des raisons de sécurité.
Que ne le disais-tu ? Les bornes d'information, je suppose que tu
maîtrises ce qu'il y a dessus, et donc que tu peux t'assurer aussi
bien de la présence de JavaScript que de l'envoi du HTTP_REFERER.
En tout cas, pour une gestion d'historique il n'y a pas photo : le
HTTP_REFERER ne permettra jamais de revenir de plus d'une page en arrière.
>> et dix mille fois
>> préférable à un lien généré à partir du HTTP_REFERER.
>
> Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie.
> La solution me paraissait pourtant universelle, du moins pour les
> navigateurs graphiques.
Un exemple tout bête pour te montrer à quel point c'est faux. Le
visiteur part de page1, puis va sur page2, page3 et page4. Il clique
ensuite quatre fois sur le bouton retour.
Avec JavaScript
page4 -> go(-1) -> page3
page3 -> go(-1) -> page2
page2 -> go(-1) -> page1
page1 -> go(-1) -> on ne bouge pas (historique vide)
Avec HTTP_REFERER
page4 -> HTTP_REFERER -> page3
page3 -> HTTP_REFERER -> page4
page4 -> HTTP_REFERER -> page3
page3 -> HTTP_REFERER -> page4
C'est bête, hein ?
>> Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
>> vers la page qui est « logiquement » avant ou après la page en cours,
>> indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
>
> C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours
> à ce genre de commande est dicté par le fait que ces pages peuvent être
> appelées à partir de 5 menus différents + des liens internes existants
> dans d'autres pages. Une barre de navigation est ainsi, au moins pour
> cette dernière raison, impossible à envisager.
D'accord. C'est donc vraiment l'équivalent du bouton BACK du navigateur
que tu cherches à réaliser, et pas indiquer une navigation qui soit
juste« logique ». Seul le navigateur lui-même pouvant savoir de façon
fiable quel était l'historique de navigation, je te conseille le lien
JavaScript à l'exception de toute autre méthode.
Fredchou
> Ce qui est curieux, c'est que même ôtés, le passage du curseur sur le lien
> de retour affiche la commande *avec* ces guillemets simples dans la barre
> d'état.
Et si tu affiches le code HTML généré ? (menu "Affichage" / "Source" dans
IE) Que lis-tu ?
Tu dois avoir un problème de cache sur ton browser. Ou bien le fichier
appelé dans le
browser n'est pas le même que celui que tu as modifié sur le serveur !
--
Fredchou
mailto:fred...@nospam.free.fr.invalid
docanski
> f... je te conseille le lien
> JavaScript à l'exception de toute autre méthode.
Bien, j'en resterai donc à JS pour les retours. Dommage que PHP ne
puisse offrir une alternative.
Merci pour tes explications lumineuses !
Fredchou
>
> Ben oui : à l'ouverture du logiciel, la fenêtre signale bien le démarrage
> d'Apache et de MySQL (feux au vert) avec la confirmation "démarrage des
> serveurs".
Il ne faut pas appeler ta page avec l'adresse "D:/Chantier PHP/Page.php"
mais avec "http://localhost/Page.php".
--
Fredchou
mailto:fred...@nospam.free.fr.invalid
Fredchou
> /Chantier PHP/< on this server." - Apache/1.3.33 Server at 127.0.0.1 Port
> 80
> lorsque j'active le lien de retour.
Il doit y avoir un problème dans ton lien <href="...">. Consulte le code
HTML généré pour voir où est l'erreur.
--
Fredchou
mailto:fred...@nospam.free.fr.invalid