Est-il préférable de rediriger vers une autre page/document en utilisant des en-têtes HTTP ou d'incorporer un message dynamique pour informer les utilisateurs de l'accès refusé?

Question

Je voudrais savoir quelle est la meilleure pratique pour informer un utilisateur que sa tentative d'accès a été refusée. Je sais qu'il ya probablement plus d'options, mais ce sont les méthodes que je songe à me:

1. informer un utilisateur sur une page dédiée « Accès refusé » atteint lorsque mon script les réoriente via header (« Location: »)
2. informer un utilisateur dans le message dans la page dynamique demandé

Je voudrais connaître les avantages contre les inconvénients. Actuellement, je peux venir avec ceux-ci:

1. Pro pour la redirection: peut-être plus obfusqués?
2. Pro pour le message dans la page demandée: moins de requêtes sur le serveur HTTP?

Answer 1

Rediriger vers une page d'erreur ou un contrôleur/action d'erreur dans la requête en cours (si vous utilisez une structure MVC).

Et assurez-vous également que vous envoyez les en-têtes HTTP corrects (le code 401 est le bon pour l'accès refusé) afin qu'un robot de recherche ou similaire comprenne ce qui se passe.

1. Pro pour la redirection: peut-être plus obfusqué?

Quel est le but de l'obfuscation?

2. Pro pour le message dans la page demandée: moins de requêtes sur le serveur HTTP?

Presque tout votre trafic sera utilisé en diffusant du contenu qui n'est pas une page refusée. Donc, je ne pense pas vraiment que ce soit une raison de décider pour l'un ou pour l'autre. Ce n'est pas comme si les utilisateurs utilisaient F5 sur des sites inaccessibles de toute façon.

EDIT: Pour summuarize: Il ne fait pas vraiment une différence, mais si vous ne pouvez pas essayer de rediriger et assurez-vous que les en-têtes appropriés sont envoyés.

EDIT2: Comme James Wheare a souligné dans les commentaires, il est contre la spécification HTTP pour rediriger vers une page d'erreur. En d'autres termes: Ne pas rediriger, mais imprimez l'erreur directement sur la page où il s'est produit avec les en-têtes appropriés.

Answer 2

Quel pourcentage de vos échecs de mot de passe sont des tentatives d'accès illégitimes et quel pourcentage sont des mots de passe mal typés? Si c'est la plupart du temps, oui, redirigez-les vers une page HTTP séparée si vous pensez que cela les rendra plus incommodes pour eux. D'un autre côté, si vous mettez simplement un message sur la même page, il est beaucoup plus facile pour les clients légitimes d'entrer leur mot de passe correct.

Answer 3

N'utilisez pas de redirection. Il vaut mieux envoyer un code d'état correct (par exemple 406) avec le document d'erreur.

Answer 4

Je vous déconseille fortement de rediriger pour la simple raison que l'URL d'origine n'est plus éditable.

Si je faisais une faute de frappe dans l'url:

http://example.com/users/jwheared 

Et suis redirigé vers:

http://example.com/denied 

Il est plus compliqué pour moi de corriger maintenant ma faute de frappe:

http://example.com/users/jwheare 

Ce même principe s'applique à 404 ou à toute autre page d'erreur. En outre, s'il s'agit d'une erreur temporaire sur le serveur, la redirection vers une autre URL supprime la possibilité d'attendre un peu, puis d'actualiser la page plus tard.

En plus de ce conseil centré sur l'utilisateur, la page d'erreur doit être desservie avec un HTTP error code (probablement 401 Non autorisé comme mentionné dans d'autres réponses).

La meilleure pratique consiste à suivre la spécification HTTP et aucun des codes d'état de redirection 3xx ne s'applique à la situation que vous avez décrite.

Editer: Un autre point important est que cela pourrait nuire à la performance de votre moteur de recherche. Si un robot d'exploration visite une page non autorisée et reçoit une redirection, toutes les pages non autorisées seront considérées comme une seule, ce qui augmentera potentiellement le classement de la page d'erreur. Si vous envoyez les en-têtes d'erreur corrects, le robot d'exploration est plus susceptible d'identifier correctement cette URL non autorisée et de l'ignorer.

Les robots d'exploration Web sont souvent des clients bêtes qui implémentent le strict minimum de la spécification HTTP. Il est utile de penser à eux ainsi que les personnes qui utilisent un navigateur Web.