Discussion :

[chrisabsy]

Bonjour,

J'ai un petite fonction de retour sur un bouton avec condition (voir code ci-dessous) qui marche parfaitement sauf sous Internet Explorer. La fonction s'effectue mais seulement sur la première partie, comme si on venait toujours de l'extérieur du site. Quelqu'un peut-il m'expliquer d'où vient le problème et s'il existe une alternative.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
function retour(){
    var Chaine = window.document.referrer;
    var Sous_Chaine_2 = 'monsite.com';
    if (Chaine.indexOf(Sous_Chaine_2) == -1){
        window.location.href="monsite.com"+ "complement-d-url";
    }else{
       history.go(-1);
    }
};

Merci déjà pour votre aide.

[chrisabsy]

À priori c'est la propriété referrer qui semble buger sur IE, quelqu'un à t'il autre chose à proposer pour un résultat équivalent.
Merci.

[Watilin]

À priori c'est la propriété referrer qui semble buger sur IE

Ça m’étonne, mais tu as peut-être raison. En gros ce que tu essayes de faire c'est :

1. Obtenir l'adresse de la page précédemment visitée
2. Tester si elle contient "monsite.com"
3. Si non, envoyer le visiteur sur monsite.com/complement-d-url
4. Si oui, reculer d'une page dans l'historique

Il y a quelques pièges à utiliser le referrer, en particulier parce que c'est une donnée facile à falisifier (voir les nombreuses extensions de Firefox proposant de faire ça). J'ai constaté que peu de site aujourd'hui ont légitimement besoin du referrer (légitimement selon moi, c'est à dire pas à des fins de pistage ou de publicité). Et les sites qui l'utilisent sont souvent de conception assez vieille. Utiliser le referrer c'est faire un pari sur l'honnêteté du visiteur. Il y a une dizaine d'années on concevait les sites comme ça, mais je pense (opinion qui n'engage que moi) que la sécurité sur le Web était prise à la légère.

Aujourd'hui on préfère se baser sur des sessions de navigation avec un identifiant de session (sessid) transmis par cookie, si possible par HTTPS. Grâce aux sessions, tu conserves côté serveur les données de session de ton visiteur. Notamment, tu peux décider de conserver son historique de navigation pendant sa session. Ainsi tu sais quelle était la « page précédente » et tu peux le renvoyer dessus. Par contre, tu ne peux pas savoir sur quel site il était avant de venir sur le tien. Mais ça, c'est une information qui touche à sa vie privée. Tu ne peux pas développer ton serveur en te basant sur une information que le visiteur n'est pas obligé de te donner.

---

Avec history.go, tu peux avoir quelques problèmes aussi. Pas pour des raisons de sécurité cette fois, mais plutôt pour des raisons de cohérence. Tous les navigateurs n'ont pas la même façon de restituer une page de l'historique :

• certains utilisent le cache, d'autres refont une requête au serveur ;
• certains redéclenchent l'évènement onload, d'autres pas ;
• etc.

HTML5 propose une API pour manipuler l'historique, mais je ne suis pas assez familier avec pour pouvoir t'en parler. (Et il semblerait qu'il y ait aussi des problèmes de compatibilité.)

Ce que je te suggère, c'est simplement de laisser tomber history, car ce n'est pas quelque chose de vital pour ton site (à mon humble avis). Disons que si tu comptes vraiment dessus, il faut ajouter du code pour corriger les problèmes de compatibilité, et le résultat ne vaut pas l'effort Si tu utilises les sessions, tu pourras sans problèmes obtenir le même comportement, mais cette fois contrôlé depuis ton serveur.

[chrisabsy]

Un grand merci pour ta réponse Watilin, même si j'avoue être complétement dépassé par celle-ci ;-)
Je vais étudier cette piste.

[Watilin]

Je vais essayer de détailler mon histoire de sessions tout en restant simple

Pour stocker des informations de session en PHP par exemple, il faut utiliser la fonction session_start(). Peut-être que tu connais déjà. Cette fonction fait plusieurs choses sous le capot : vérifier qu'un cookie de session est présent, en créer un si besoin, et récupérer les informations associées à ce cookie, informations qui sont stockées côté serveur comme je te l'ai dit. Dans le script PHP, elles sont accessibles via la variable globale $_SESSION. Tu peux y stocker à peu près n'importe quoi. Pour y stocker l'historique de l'utilisateur, tu peux par exemple utiliser un tableau. Imagine que toutes les pages PHP de ton site commencent par ce bout de code :

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?php
session_start();
 
// initialise le tableau s'il n'existe pas
if (!isset($_SESSION['historique'])) {
   $_SESSION['historique'] = array();
}
 
// ajoute l'adresse actuelle
$_SESSION['historique'][] = $_SERVER['REQUEST_URI'];
 
// affiche le tableau
echo '<p>Historique de navigation pour cette session :</p>';
echo '<pre>';
print_r($_SESSION['historique']);
echo '</pre>';
 
?>

Tu verras s'agrandir l'historique au fur et à mesure que tu navigues sur le site. Et avec Firebug (ou une autre console) tu peux vérifier que l'information n'est pas dans les cookies : il y a seulement un cookie PHPSESSID qui contient l'identifiant de la session (dans certains cas, cet identifiant est visible dans l'URL).

[iakou]

Bonjour.

- Vous devriez en 1er tester window.document.referrer : En principe il contient quelquechose qd on vient par un LIEN d'un site. En revanche, il sera VIDE si on vient d'un favori (Bookmark) ou si on a tapé à la main dans la barre d'url...
- Attention, j'ai bien précisé en principe ! Grosso-modo cela dépend des serveurs...
- On peut imaginer qu'il puisse contenir n'importe quoi !

- Pour ce que voulez faire, si le referrer est vide OU contient autre chose que 'monsite.com' : alors history.go(-1). Ce qui est différent de ce que vous avez écrit...

- Par ailleurs, concernant votre code :
- Votre variable 'Sous_Chaine_2' est inutile, placez la chaine correspondante directement dans la methode indexOf.
- Attention la methode IndexOf est sensible à la casse !
- Dans un "if else" pas besoin d'accolade quand il n'y a qu'une seule instruction.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
function retour()
     {
var Chaine = window.document.referrer ;
 
if ( Chaine.length == 0 || Chaine.indexOf('monsite.com') == -1 )
     history.go(-1) ;
else
     window.location.href="monsite.com" + "complement-d-url" ;
     }

[Watilin]

- Dans un "if else" pas besoin d'accolade quand il n'y a qu'une seule instruction.

C'est certes vrai. Mais c'est le dernier conseil que je donnerais à n'importe qui, peu importe son niveau. Oublier les accolades est très généralement considéré comme une mauvaise pratique, car elle a de fortes chances de créer une erreur lors de modifications futures du code. Imaginons que j'ai ce code au départ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (condition)
   instruction1;

Quelques semaines plus tard, je décide de rajouter une instruction dans le bloc if. Je suis fatigué et/ou je veux faire ça vite, et du coup je ne fais pas attention.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (condition)
   instruction1;
   instruction2; // cette instruction n'est pas dans le bloc !

Une erreur comme ça est facile à faire, et le pire c'est que même en relisant le code on peut passer plusieurs fois sur la ligne sans comprendre que le problème vient de là.

Personnellement, je m'autorise l'exception dans un cas très particulier :

• quand l'instruction est courte et peut tenir sur la même ligne que le if
• et quand il n'y a pas de else

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (condition) instruction_courte;

Mon principal argument c'est qu'à la modification du code, je suis obligé de passer à la ligne et c'est quasiment impossible que j'oublie de rajouter les accolades à ce moment-là. Mais c'est un choix très personnel, et même avec cette forme j'ai déjà eu des reproches.

Moralité : toujours ajouter les accolades pour écarter les risques d'erreurs.

[iakou]

Bonjour Watilin !
Oui vous avez tout a fait raison sur cette question de forme (c'est ce que recommande le W3C).
En revanche, concernant le problème de fond, je ne pense pas qu'il faille orienter 'chrisabsy' vers une usine à gaz.
Ce n'est quand même qu'un petit aiguillage !
Quant à history.go(-1), peu importe comment le navigateur traite l'instructtion, l'essentiel c'est qu'elle soit exécutée !
Le Mieux est souvent l'ennemi du Bien. D'ailleurs n'avez vous pas relevé que ce graphiste, avait été désorienté par votre approche.
Cdlt.

[Watilin]

Bonjour Watilin !

Bonsoir Iakou !

concernant le problème de fond, je ne pense pas qu'il faille orienter 'chrisabsy' vers une usine à gaz.

Tu parles des accolades ou de la gestion des sessions ?

Ce n'est quand même qu'un petit aiguillage !

Petit aiguillage peut-être, mais la tendance actuelle est de ne pas trop compter sur le referrer. J'ai jugé bon de l'indiquer car JavaScript souffre d'un grand nombre de documents obsolètes. Il faut propager les idées actuelles !

Quant à history.go(-1), peu importe comment le navigateur traite l'instructtion, l'essentiel c'est qu'elle soit exécutée !
Le Mieux est souvent l'ennemi du Bien.

Je n'ai peut-être pas utilisé les bons arguments, mais je reste persuadé que history.go(-1) n'est pas suffisamment utile pour justifier son emploi. Je ne vois pas, par exemple, des sites web riches comme Google ou Facebook utiliser cette fonction (du moins, en dehors de l'API HTML5 dont j'ai parlé). De plus, pour moi, un site n'est pas censé faire des actions à la place de l'utilisateur. Précisément history.go(-1) a le même effet que si l'utilisateur avait cliqué sur le bouton « précédent ». Or, ce n'est pas lui qui fait l'action. Il peut donc être dérouté : son historique ne contient plus exactement ce qu'il attendait.

Par exemple l'utilisateur vient du site siteA et arrive sur mon propre site monsite. Celui-ci le renvoie sur la page précédente, donc à nouveau le siteA.

L'utilisateur croit avoir cet historique :

siteA --> monsite --> siteA

Alors que l'historique contient en réalité :

siteA

Ça peut te paraître dérisoire que je dise que l'utilisateur puisse être « dérouté » par ceci, mais je suis sûr qu'il y a des gens dans ton entourage qui ne sont pas à l'aise avec le concept d'historique du navigateur bien qu'ils utilisent Internet tous les jours. Il ne faut pas détourner un comportement communément admis, c'est le principe de moindre surprise.