de toutes façons il n'y a pas que le bouton de back pour retourner à une page précédente, ça se fait aussi au clavier.
Très juste.
Le problème est presque sans fin.
En effet, c'est ce dont je m'aperçois. Ne pourrait on pas empêcher l'historisation des pages ?
L'hitorique est du read only ...
Comme ca les boutons seraient inopérant.
<https://developer.mozilla.org/en/DOM/window.history> Toutes les features de window chez Mozilla : <https://developer.mozilla.org/En/DOM/Window>
Chez M$ : <http://support.microsoft.com/kb/913721> <http://msdn.microsoft.com/en-us/library/microsoft.enterprisemanagement.monitoring.partialmonitoringobject.getmaintenancewindowhistory.aspx> <http://technet.microsoft.com/en-us/library/bb457150.aspx#ECAA>
Bruno Desthuilliers
Thanaos a écrit :
SAM a écrit :
de toutes façons il n'y a pas que le bouton de back pour retourner à une page précédente, ça se fait aussi au clavier.
Très juste.
Le problème est presque sans fin.
En effet, c'est ce dont je m'aperçois. Ne pourrait on pas empêcher l'historisation des pages ? Comme ca les boutons seraient inopérant.
Comme le disait M. de la Palisse, à partir du moment où une url est accessible, tu ne peux _rien_ faire pour empêcher un client quelconque d'y accéder. Dis toi bien que non seulement certains navigateurs ne supportent pas javascript, mais qu'en plus rien ne garanti que le client soit un navigateur (n'importe quel programme dans un langage capable d'ouvrir une connexion réseau - autant dire n'importe quel programme tout court - peut émettre des requêtes HTTP).
En d'autres termes, la seule solution viable pour empêcher le redéclenchement intempestif d'un traitement sur le serveur, c'est de mettre en place un marqueur qui permette au serveur de savoir si on est dans la bonne configuration ou non. Le mieux est d'utiliser un mécanisme de session (à durée de vie réduite) qui stocke un UUID aléatoire, (différent pour chaque page of course) au moment de servir une page, lequel UUID doit _aussi_ être présent dans la requête (dans la querystring en GET, dans le corps en POST). Avant de servir la page, le serveur compare les deux UUID. S'ils correspondent, il y a de fortes chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
Thanaos a écrit :
SAM a écrit :
de toutes façons il n'y a pas que le bouton de back pour retourner à
une page précédente, ça se fait aussi au clavier.
Très juste.
Le problème est presque sans fin.
En effet, c'est ce dont je m'aperçois.
Ne pourrait on pas empêcher l'historisation des pages ?
Comme ca les boutons seraient inopérant.
Comme le disait M. de la Palisse, à partir du moment où une url est
accessible, tu ne peux _rien_ faire pour empêcher un client quelconque
d'y accéder. Dis toi bien que non seulement certains navigateurs ne
supportent pas javascript, mais qu'en plus rien ne garanti que le client
soit un navigateur (n'importe quel programme dans un langage capable
d'ouvrir une connexion réseau - autant dire n'importe quel programme
tout court - peut émettre des requêtes HTTP).
En d'autres termes, la seule solution viable pour empêcher le
redéclenchement intempestif d'un traitement sur le serveur, c'est de
mettre en place un marqueur qui permette au serveur de savoir si on est
dans la bonne configuration ou non. Le mieux est d'utiliser un
mécanisme de session (à durée de vie réduite) qui stocke un UUID
aléatoire, (différent pour chaque page of course) au moment de servir
une page, lequel UUID doit _aussi_ être présent dans la requête (dans la
querystring en GET, dans le corps en POST). Avant de servir la page, le
serveur compare les deux UUID. S'ils correspondent, il y a de fortes
chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
de toutes façons il n'y a pas que le bouton de back pour retourner à une page précédente, ça se fait aussi au clavier.
Très juste.
Le problème est presque sans fin.
En effet, c'est ce dont je m'aperçois. Ne pourrait on pas empêcher l'historisation des pages ? Comme ca les boutons seraient inopérant.
Comme le disait M. de la Palisse, à partir du moment où une url est accessible, tu ne peux _rien_ faire pour empêcher un client quelconque d'y accéder. Dis toi bien que non seulement certains navigateurs ne supportent pas javascript, mais qu'en plus rien ne garanti que le client soit un navigateur (n'importe quel programme dans un langage capable d'ouvrir une connexion réseau - autant dire n'importe quel programme tout court - peut émettre des requêtes HTTP).
En d'autres termes, la seule solution viable pour empêcher le redéclenchement intempestif d'un traitement sur le serveur, c'est de mettre en place un marqueur qui permette au serveur de savoir si on est dans la bonne configuration ou non. Le mieux est d'utiliser un mécanisme de session (à durée de vie réduite) qui stocke un UUID aléatoire, (différent pour chaque page of course) au moment de servir une page, lequel UUID doit _aussi_ être présent dans la requête (dans la querystring en GET, dans le corps en POST). Avant de servir la page, le serveur compare les deux UUID. S'ils correspondent, il y a de fortes chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
Thanaos
Bruno Desthuilliers a écrit :
Thanaos a écrit :
Ne pourrait on pas empêcher l'historisation des pages ? Comme ca les boutons seraient inopérant.
En d'autres termes, la seule solution viable pour empêcher le redéclenchement intempestif d'un traitement sur le serveur, c'est de mettre en place un marqueur qui permette au serveur de savoir si on est dans la bonne configuration ou non. Le mieux est d'utiliser un mécanisme de session (à durée de vie réduite) qui stocke un UUID aléatoire, (différent pour chaque page of course) au moment de servir une page, lequel UUID doit _aussi_ être présent dans la requête (dans la querystring en GET, dans le corps en POST). Avant de servir la page, le serveur compare les deux UUID. S'ils correspondent, il y a de fortes chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
Cette méthode s'apparente à la gestion des timestamps et de la concurrence d'acces. Je te remercie pour cette idée qui semble répondre à ma question. C'est seulement plus compliqué et plus long a mettre en oeuvre. Je vais donc approfondir le sujet.
Je remercie toutes les personnes actives sur cette question
Bruno Desthuilliers a écrit :
Thanaos a écrit :
Ne pourrait on pas empêcher l'historisation des pages ?
Comme ca les boutons seraient inopérant.
En d'autres termes, la seule solution viable pour empêcher le
redéclenchement intempestif d'un traitement sur le serveur, c'est de
mettre en place un marqueur qui permette au serveur de savoir si on est
dans la bonne configuration ou non. Le mieux est d'utiliser un
mécanisme de session (à durée de vie réduite) qui stocke un UUID
aléatoire, (différent pour chaque page of course) au moment de servir
une page, lequel UUID doit _aussi_ être présent dans la requête (dans la
querystring en GET, dans le corps en POST). Avant de servir la page, le
serveur compare les deux UUID. S'ils correspondent, il y a de fortes
chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
Cette méthode s'apparente à la gestion des timestamps et de la
concurrence d'acces. Je te remercie pour cette idée qui semble répondre
à ma question. C'est seulement plus compliqué et plus long a mettre en
oeuvre.
Je vais donc approfondir le sujet.
Je remercie toutes les personnes actives sur cette question
Ne pourrait on pas empêcher l'historisation des pages ? Comme ca les boutons seraient inopérant.
En d'autres termes, la seule solution viable pour empêcher le redéclenchement intempestif d'un traitement sur le serveur, c'est de mettre en place un marqueur qui permette au serveur de savoir si on est dans la bonne configuration ou non. Le mieux est d'utiliser un mécanisme de session (à durée de vie réduite) qui stocke un UUID aléatoire, (différent pour chaque page of course) au moment de servir une page, lequel UUID doit _aussi_ être présent dans la requête (dans la querystring en GET, dans le corps en POST). Avant de servir la page, le serveur compare les deux UUID. S'ils correspondent, il y a de fortes chances que tout aille bien. Sinon, rediriger vers la ressource appropriée.
Cette méthode s'apparente à la gestion des timestamps et de la concurrence d'acces. Je te remercie pour cette idée qui semble répondre à ma question. C'est seulement plus compliqué et plus long a mettre en oeuvre. Je vais donc approfondir le sujet.
Je remercie toutes les personnes actives sur cette question
