Est-il possible d'envoyer un 401 non autorisé et rediriger (avec un emplacement)?

Je viens très tard ici, mais je pensais ajouter mes deux cents. Si je comprends bien, le désir est d'indiquer que l'utilisateur n'a pas l'autorisation correcte et de l'inviter à se connecter. Rudie naturellement voudrait retourner 401 non autorisé (parce que l'utilisateur doit autoriser par un mécanisme, par exemple. connectez-vous), et aussi les transférer à la page de connexion - mais ce n'est pas très facile à accomplir 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 cela a été suggéré dans une autre réponse. Cependant, permettez-moi de jeter un oeil à cela du point de vue de la pratique établie/meilleure.

Cas de Test 1: Facebook

La navigation vers une page Facebook protégée (mon profil utilisateur) lors de la déconnexion entraîne une réponse 404 Not Found. Facebook sert un usage général "cette page n'est pas disponible" page, qui comprend également un formulaire de connexion. Intéressant. Encore plus intéressant: quand je navigue vers la page "événements", on me sert une réponse 302 qui transmet à une page de connexion (qui renvoie une réponse 200). Donc, je suppose que leur idée est de retourner 302 pour les pages que nous savons existent, mais servir 404 pour les pages qui peuvent ou peuvent ne pas exister (par exemple. pour protéger votre vie privée).

Cas de Test 2: boîte de réception Google

La navigation vers ma boîte de réception lorsque je suis déconnecté renvoie 302 et me redirige vers une page de connexion, similaire à Facebook. Je n'étais pas capable de comprendre comment faire mon Google+ profil privé, donc pas de données de test là...

Cas D'essai 3: Amazon.com

La navigation vers Mon historique de commandes lorsque je suis déconnecté renvoie 302 et me redirige vers une page de connexion comme précédemment. Amazon n'a pas le concept d'une page" Profil", donc je ne peux pas tester cela ici non plus.

Pour résumer les cas de test ici, il semble être la meilleure pratique de renvoyer un 302 trouvé et de le transmettre à une page de connexion si l'Utilisateur a besoin de se connecter (bien que je dirais 303 voir autre est en fait plus approprié). Ceci est bien sûr juste dans le cas où un utilisateur humain réel doit entrer un nom d'utilisateur et un mot de passe dans un formulaire html. Pour d'autres types d'authentification (par exemple. de base, clé api, etc.), 401 non autorisé est évidemment la réponse appropriée. Dans ce cas, il n'est pas nécessaire pour avancer vers une page de connexion.

3xx signifie rediriger
4xx signifie que le navigateur a fait quelque chose de mal.

Il y a une raison pour laquelle les codes sont divisés comme ils sont - ils ne se mélangent pas;)

En plus des bonnes réponses de Kolink et David (+1), Je voudrais souligner que vous essayez de changer la sémantique du protocole HTTP en retournant un 401 et en disant au navigateur de rediriger. Ce n'est pas ainsi que le protocole HTTP est destiné à fonctionner, et si vous trouvez un moyen d'obtenir ce résultat, les clients HTTP trouveront que le comportement de votre service est non standard.

Soit vous envoyez un 401 et permettez au navigateur de le gérer, soit vous gérez la situation différemment (par exemple, comme l'a suggéré un commentateur, rediriger vers une page de connexion ou peut-être vers une page expliquant pourquoi l'utilisateur n'avait pas accès).

Voici une façon propre:

Sur la page 401, vous pouvez choisir la " vue "à envoyer en fonction de l'en-tête" accepter " dans la requête.

Si l'accepter, c'est application/json, alors vous pouvez inclure le corps:

{"status":401;"message":"Authentication required"}

Si la "accepter" est text/html, alors vous pouvez inclure le corps:

<form action="/signin" method="post">
    <!-- bla bla -->
    <input type="hidden" name="redirect" value="[URL ENCODE REQUEST URI]">
</form>

Ensuite, vous rencontrez la même question... donnez-vous un 200 OK ou 302 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 action soit la même URL de page, mais surveillez XSS Si vous placez le request_uri fourni par l'utilisateur dans l'attribut action de formulaire.

Vous pouvez envoyer 401, puis dans le corps de réponse, vous pouvez envoyer window. location='domain.com'. cependant, l'Utilisateur sera immédiatement redirigé sans savoir que 401 a eu lieu.

Les navigateurs Web ne sont pas des clients REST. Respectez le statut d'envoi 200 avec un en-tête D'emplacement et aucun contenu de corps. Les redirections 30x sont pour les pages qui ont été déplacées. Aucun autre en-tête de code/emplacement d'état ne devrait être redirigé dans un navigateur web.

Sinon, votre serveur web peut avoir des pages d'erreur configurables. Vous pouvez ajouter javascript à la page d'erreur à rediriger.

Cela Pourrait-il être ce dont vous avez besoin? Je suis tombé sur cela moi-même avant avec la même question.

if(user_has_no_rights()) 
{ 
   header('HTTP/1.1 401 Unauthorized');
   echo $this->requestAction('anothercontroller/action', 
array('return')); 

   $this->autoRender = false;
   $this->layout = ''; 
   die(); 
}