Quelle est l'exigence du navigateur de montrer le message omniprésent "Cette page a expiré" lorsque l'utilisateur frappe le bouton arrière?
Quels sont les moyens conviviaux d'empêcher l'utilisateur d'utiliser le bouton arrière d'une webApp?
5 Réponses :
Vous devez définir l'option de contrôle de pragma-cache dans les en-têtes HTTP: http://www.w3.org/protocols/rfc2616/ RFC2616-SEC14.HTML # SEC14.9
Cependant, du point de vue de la convivialité, cela est découragé l'approche de la question. Je vous encourage fortement à rechercher d'autres options.
PS: tel que proposé par Steve, la redirection via GET est la solution appropriée (ou vérifiez le mouvement de la page avec JS).
Eh bien, par défaut chaque fois que vous avez affaire à un poste de formulaire, puis l'utilisateur frappe puis rafraîchissez-le puis ils verront que le message indiquant que le navigateur est de soumettre des données. Mais si la page est définie pour expirer immédiatement, ils n'auront même pas à frapper l'actualisation et ils verront que la page a expiré le message lorsqu'il a atteint son retour.
Pour éviter les deux messages, il y a quelques choses à essayer:
1) Utilisez un formulaire obtenir à la place. Cela dépend de ce que vous faites, mais ce n'est pas toujours une bonne solution car il existe toujours des restrictions de taille sur une demande d'obtention. Et les informations sont transmises dans la QueryString qui n'est pas la plus sûre des options.
- ou -
2) Effectuez une redirection du côté serveur vers une page différente après le poste de formulaire.
On dirait qu'une question similaire a été répondue ici:
comme une troisième option, on pourrait empêcher un utilisateur de revenir dans leur navigateur. La seule fois où j'ai ressenti un besoin de faire cela était de les empêcher de faire quelque chose de stupide, tel que payer deux fois. Bien qu'il y ait de meilleures méthodes côté serveur pour gérer cela. Si votre site utilise des sessions, vous pouvez les empêcher de payer deux fois par premier cache de désactivation de la page de paiement et de la définition d'expiration immédiatement. Ensuite, vous pouvez utiliser un drapeau de certaines sortes stockées dans une session qui modifiera en réalité le comportement de la page si vous y retournerez.
Je ne suis pas sûr que cela soit une pratique standard, mais je résolvez généralement ce problème en n'envoyant pas d'en-tête de variables pour IE. Dans Apache, vous pouvez mettre les suivants dans httpd.conf: selon le RFC : La valeur du champ Vary indique l'ensemble
des champs d'en-tête de demande qui sont entièrement
détermine, alors que la réponse est
frais, si un cache est autorisé à
Utilisez la réponse à la réponse à un
demande ultérieure sans
Révalidation.
L'effet pratique est que lorsque vous allez "retour" à un post, c'est-à-dire que vous obtenez simplement la page du cache historique. Aucune demande ne va du côté du serveur. Je peux voir cela clairement dans httpwatch. Je serais intéressé d'entendre des effets secondaires potentiels de cette approche.
Essayez d'utiliser le code suivant dans la page_LOAD
Response.Cache.SetCacheability(HttpCacheability.Private)
Cette solution fonctionne parfaitement pour les formes Web ASP.NET.
Utilisez l'un des éléments suivants avant / remarque: langue est php session_start :
y compris quelle langue ce serait utile
Il serait préférable de concevoir votre application afin que le bouton arrière ait une signification sensible. Je trouve que cela m'excite lorsque je ne suis pas autorisé à utiliser le bouton arrière.
Peter, je suis d'accord. Il y a des moments (tels que le processus de caisse d'un site de commerce électronique) lorsque vous pourriez être tenté d'empêcher l'utilisateur de revenir. Cependant, il y a une meilleure solution côté serveur à ce problème que je suggère dans ma réponse.
@Peter, je suis tout à fait d'accord, mais je traite avec les flux de travail afin que le bouton arrière ne s'applique pas ici.