détecter si l'utilisateur a cliqué sur "page précédente" ou modifié manuellement l'URL

Bonjour

Je travaille sur un projet qui utilise JSF et au moins une servlet. Mon intention est de faire en sorte que si l'utilisateur distant clique sur le bouton "page précédente" ou modifie manuellement l'URL, la requête soit purement et simplement ignorée et qu'au mieux il ne se passe rien, ou a défaut que la page où il était lorsqu'il a fait cette manipulation soit rechargée.

A charge ensuite pour moi de prévoir des boutons internes à mon application qui permettent de naviguer dedans.

Je sais qu'il doit être possible de récupérer ce type d'infos puisque certains sites font des stats où ils disent d'où on a cliqué pour les visiter.

Savez vous comment faire?

Citation:

---

Envoyé par Aldian

Je sais qu'il doit être possible de récupérer ce type d'infos puisque certains sites font des stats où ils disent d'où on a cliqué pour les visiter.

---

Bonjour,

Les stats que tu indiques sont extraites d'un fichier log. Par exemple pour HTTP Server Apache, c'est le fichier access_log ou access.log.

Chaque accès au serveur est enregistré dans ce fichier par une ligne.

Chaque ligne est de la forme:
127.0.0.1 - - [30/May/1998:17:27:15 +0200] "GET /myPage.jsp HTTP/1.1" 200 5687

Les différents champs sont l'adresse IP, la date et heure de la réponse, la requête, le code de la réponse et la taille de la réponse.

Je vois très bien ce que tu veux dire, mais je ne pense pas que ça réponde à la problématique.

En effet ces lignes de logs indiquent les pages qui ont été demandées, mais pas le lien qui a été cliqué, ou la page de provenance.

Or si je regarde les statistiques de mon blog wordpress, je peux voir que "tant de vos visiteurs viennent de google", "tant ont cliqué sur des liens internes", "tant viennent de www.toto.com", etc.

C'est à ça que je fais référence. Je soupçonne que ces infos doivent se situer quelque part dans le header http du get, reste à savoir où?


EDIT: J'ai trouvé comment faire, c'est le champs Referer de la requête Http. Ca peut fournir un moyen de réponse à ma question originale : "pas de referer" => "opération anormale".

Mais il y a peut être plus habile, je ne marque donc pas encore le thread comme résolu.

Attention l'entête Referer n'est pas toujours renseignée correctement. Elle est supprimée par certains utilitaires pour garantir " l'anonymat" de l'utilisateur.

-> Le Referer n'est pas toujours correct (comme dit, parfois il n'est pas présent dans le navigateur)
-> Si tu fais un back puis un reload, il y a des chance que le referer soit le même que la fois précédente.

Quel est le but de toute cette opération? C'est un besoin pour le moins curieux, qui laisse à supposer qu'il ne s'agit pas en réalité d'un besoin, mais d'un moyen mal choisi pour satisfaire un besoin que tu n'a pas exprimé ici.

Je vais essayer de reformuler alors:

Je développe une application suivant l'architecture JSF/Spring/Hibernate. Je couvre un certain nombre de risques techniques comme l'authentification automatique de l'utilisateur (en http), et la conservation de la session. Le client peut naviguer sur le site en utilisant les liens fournis dans le corps des pages en fonction de ce que je l'autorise à faire. Et comme je suis bon prince, je lui fournis aussi un bouton logout.


Le risque que je cherche à couvrir, et qui m'a amené à poster ce message, c'est ce qui se passera si l'utilisateur essaye de modifier manuellement l'url sans cliquer sur un bouton, s'il clique sur page précédente, s'il ouvre un lien dans un nouvel onglet, etc. Ce genre de chose si je ne le gère pas est susceptible de générer des plantages, en particulier dans les cas où des ressources ont été réservées en écriture, ou auraient du l'être.


Et donc je m'interroge sur les moyens de circonvenir aux diverses possibilités.

Que se passe-t-il si il ouvre dans un nouvel onglet -> Tu lui affiche la page qu'il demande.

L'authentification, c'est à gérer au niveau des action effectuée, des urls affichée, pas au niveau des boutons affichés. Si l'utilisateur chipotte une url, soit c'est une url a laquelle il a le droit d'accéder -> alors tu affiche. Soit il a pas le droit -> alors t'as normalement pas besoin du referer pour le savoir. Si tu commence à avoir besoin de ce genre d'information pour déterminer si l'utilisateur a le droit ou pas, tu t'expose à de sacrés trous de sécurité puisque tu dépend d'une info qui viens du navigateur et pas d'une info qui est dans le serveur.


Ca m'a plutot l'air d'un design bancal qui cherche à empecher l'utilisateur d'utiliser un navigateur de la manière à laquelle il s'attends à pouvoir l'utiliser. Pourquoi ça te pose un problème qu'il affiche deux pages en parallèle? Normalement dans l'URL ou dans le POST doit se trouver les informations nécessaires pour différentier les requêtes. Su ce forum, si j'ouvre deux pages "répondre" sur deux discussion différentes, dans deux pages différentes, ça ne se mélange pas. On dirait le genre de problème qu'on a quand on a mis en scope session des informations qui devraient avoir été mises en scope request.
Voilà pour le background.

Donc si ton problème et, comme c'est souvent le cas, empêcher un utilisateur d'effectuer deux fois la même action (ce qui, là est un problème légitime), il faut associer sur l'url ou dans les paramètres du formulaire un numéro unique. Dans ton action, tu le détecte, et tu regarde dans la session user si il a déjà effectué cette action. C'est donc coté server, à postériori, de détecter les problème de ce style.

Si ton problème c'est d'empêcher un utilisateur de faire un bookmark de la page, d'ouvrir des onglets ou de revenir dans son historique, tout solution sera bancale et fera profondément ch*** ton utilisateur ;). C'est d'ailleurs très désagréable les site qui t'empêchent d'utiliser tes bookmarks normalement ou de revenir en arrière.... (comme celui d'un gros assureur en Belgique que je ne nommerais pas et dont la navigation sur le site est une vraie galère du coup)

Merci beaucoup d'avoir pris la peine de cette longue réponse. Concernant l'authentification, je ne la mentionnais que pour information, car j'ai déjà résolu le problème à l'aide d'un filtre.

Concernant la confusion de scope session/request, tu as probablement raison, c'est la conclusion à laquelle j'étais venu aussi. Dommage de devoir repasser en scope request, le scope session était tellement pratique :).

Merci pour l'idée du numéro unique associé non pas à la page comme je le pensais, mais plutôt à l'action, je vais creuser cet aspect.


Pour finir, je ne cherche pas à embêter l'utilisateur pour le plaisir, mais par contre je veux l'empêcher de planter mon application avec des actions tordues.

Problème résolu pour le moment :ccool: