Est-il possible d'envoyer un 401 non autorisé ET de redirection (avec un Emplacement)?
Je voudrais envoyer un 401 Unauthorized
ET de rediriger le client quelque part. Cependant:
si je fais comme ça:
header('HTTP/1.1 401 Unauthorized');
header('Location: /');
le serveur envoie un 302 Found
avec Location
, donc pas un 401 Unauthorized
.
Si je fais comme ça:
header('Location: /');
header('HTTP/1.1 401 Unauthorized');
le navigateur reçoit un 401 Unauthorized
et un Location
, mais ne redirige pas.
(IE 9 et Chrome 16 se comportent de la même façon, donc je suppose que c'est correct)
Peut-être que je suis mauvais usage de HTTP? J'aimerais que mon interface de l'application pour être exactement le même pour tous les clients: navigateur texte, un navigateur moderne, les appels d'API etc. Le 401 + texte de la réponse serait de dire à un utilisateur API de quoi il s'agit. La redirection est utile pour un navigateur.
Est-il une (bonne) manière?
Vous devez vous connecter pour publier un commentaire.
Par définition (voir La RFC 2616), le
HTTP 302
code de réponse est le code de redirection. Sans elle, l'emplacement de l'en-tête peut être ignoré.Cependant, vous pouvez envoyer un
HTTP 401
réponse et encore de la sortie d'affichage. Au lieu de rediriger l'utilisateur vers une page d'erreur, il vous suffit d'écrire votre contenu que vous souhaitez envoyer dans le corps HTTP dans la même demande.J'arrive très tard ici, mais je pensais que je voudrais ajouter mon grain de sel. Si je comprends bien, le désir est pour indiquer que l'utilisateur n'a pas la bonne autorisation et de les inciter à se connecter. : Rudie naturellement voudrais revenir 401 non autorisé (du fait que l'utilisateur doit autoriser par un mécanisme, par exemple. la connexion), et également de les transmettre à la page de connexion - mais ce n'est pas très facile à réaliser et n'est pas pris en charge par la plupart des bibliothèques. Une solution consiste à afficher la page de connexion dans le corps de la réponse 401, comme il était suggéré dans une autre réponse. Toutefois, permettez-moi de prendre un coup d'oeil à ce du point de vue de la établi sur les pratiques exemplaires.
Cas de Test 1: Facebook
Navigation protégé Facebook page (mon profil d'utilisateur), tandis que consigné les résultats dans un 404 not Found réponse. Facebook sert un objectif général de "cette page n'est pas disponible la page", qui comprend également un formulaire de connexion. Intéressant. Encore plus intéressant: lorsque je navigue à l' "événements" à la page, je suis servi une réponse 302 qui redirige vers une page de connexion (qui renvoie une réponse 200). Donc je suppose que leur idée est de retour 302 pour les pages que nous savoir existent, mais servent 404 pour les pages qui peut ou peut ne pas exister (par exemple. pour protéger votre vie privée).
Cas de Test 2: Google Boîte de réception
De la navigation à ma boîte de réception lorsque je suis déconnecté retourne 302 et en avant de moi pour une page de connexion, similaire à Facebook. Je n'étais pas en mesure de comprendre comment faire pour que mon profil Google+ privé donc pas de données de test là...
Cas de Test 3: Amazon.com
Accédant à l'historique de ma commande quand je suis déconnecté retourne 302 et en avant de moi pour une page de connexion comme avant. Amazon n'a pas de concept d'un "profil" de la page donc je ne peux pas test ici.
Pour résumer le cas de test ici, il semble être les meilleures pratiques de retour d'un 302 Found et de l'avant vers une page de connexion si l'utilisateur doit se connecter (bien que je dirais 303 Voir Autre est en fait la plus appropriée). Bien sûr, cela est juste dans le cas où un humain réel les besoins de l'utilisateur pour la saisie d'un nom d'utilisateur et le mot de passe dans un formulaire html. Pour d'autres types d'authentification (par exemple. de base, la clé api, etc), 401 non autorisé est de toute évidence la réponse appropriée. Dans ce cas, il n'est pas nécessaire pour avancer vers une page de connexion.
3xx
moyens de Redirection4xx
signifie que le navigateur fait quelque chose de mal.Il ya une raison pourquoi les codes sont réparties de la façon dont ils - elles ne se mélangent pas 😉
En plus de l'amende de réponses à partir de Kolink et David (+1), je tiens à souligner que vous essayez de changer la sémantique du protocole HTTP par tous deux de retour 401 ET qui dit au navigateur de redirection. Ce n'est pas la façon dont le protocole HTTP est destiné à travailler, et si vous ne trouver un moyen d'obtenir ce résultat, les clients HTTP trouverez le comportement de votre service non-standard.
Soit vous envoyez un 401 et de permettre au navigateur de traiter avec elle, ou vous gérer la situation différemment (par exemple, comme un intervenant a suggéré que, de rediriger vers une page de connexion ou peut-être une page expliquant pourquoi l'utilisateur n'avaient pas accès).
Ici est une méthode propre:
Sur la 401 page, vous pouvez choisir "afficher" pour envoyer basé sur "accepter" en-tête de la demande.
Si l'accepter, c'est
application/json
, vous pouvez inclure le corps:Si la "accepter" est
text/html
, vous pouvez inclure le corps:Ensuite, vous exécutez dans la même question... avez-vous un problème
200 OK
ou un302 Found
sur une connexion réussie? (voir ce que j'ai fait là? )Si vous pouvez gérer l'authentification sur n'importe quelle page, vous pouvez juste avoir la forme d'action la même URL de la page, mais regarder pour les XSS si vous mettez de l'utilisateur fourni request_uri dans l'attribut action du formulaire.
Vous pouvez envoyer 401 et puis dans le corps de la réponse, vous pouvez envoyer la fenêtre.location='domain.com'. Toutefois, l'utilisateur sera immédiatement redirigé sans savoir qu'401 eu lieu.
Navigateurs Web ne sont pas en RESTE des clients. Tenir à l'envoi de 200 avec un en-tête location et pas de contenu du corps. La 30x redirections sont pour les pages qui ont déménagé. Pas d'autres codes d'état/Location-tête doit être prévu pour rediriger dans un navigateur web.
Sinon, votre serveur web peut avoir configurable pages d'erreur. Vous pouvez ajouter du code javascript à la page d'erreur de redirection.