Devrais-je renvoyer un code de statut http 401 sur un formulaire de connexion basé sur html?
Devrais-je renvoyer un code de statut http 401 sur un formulaire de connexion basé sur html? La page est un formulaire de connexion dédié et ne contient aucun autre contenu significatif, mais uniquement la structure du site. Toutefois, l’URL peut s’appliquer à une page dont le contenu est significatif, mais nécessite une connexion. Notez que cette configuration ne renvoie que le code d'état 401 et ne demande pas à l'utilisateur de s'authentifier de base.
En regardant les normes, il semble que 401 soit un code d’état inapproprié pour les formulaires de connexion basés sur html. Cependant, je n'ai jamais eu connaissance ni entendu parler de conséquences néfastes d'une telle décision.
Lors de l'envoi de 401, "La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (paragraphe 14.47) contenant un défi applicable à la ressource demandée."
exigence mentionnée ici:
http://tools.ietf.org/html/rfc2616#section-10.4.2
détaillé ici:
http://tools.ietf.org/html/rfc2617#section-3.2.1
Je sais qu’il ya des moyens de contourner les moteurs de recherche pour les convaincre d’indexer ou non des pages en fonction de la présence d’un formulaire de connexion, mais je préférerais utiliser les codes de statut http, en particulier 401, car leur définition semble être un correspondance parfaite si ce n'est pour l'exigence d'en-tête WWW-Authenticate.
Y a-t-il une raison pour laquelle je ne devrais pas utiliser le 401 dans ce cas? Sémantiquement, y a-t-il une différence entre ne pas être autorisé au niveau http et être autorisé au niveau de l'application? Évidemment, vous pouvez avoir les deux, mais l'authentification au niveau http n'est-elle pas une simple facilité à ne pas l'implémenter au niveau de l'application?
Comme vous le constatez, RFC 2616 requiert qu'une réponse 401 soit accompagnée d'un en-tête RFC 2617 WWW-Authenticate. Je suppose que vous pourriez techniquement satisfaire à cette exigence en envoyant un en-tête factice du type:
WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"
mais je n'ai aucune idée de ce que les navigateurs feront si on leur présente une réponse 401 ne contenant aucun défi qu'ils comprennent. Je suppose que la plupart sinon la totalité d'entre eux présenteraient le corps de la requête à l'utilisateur (comme le dit la RFC 2616 qu'ils devraient le faire si l'authentification échouait), mais aucun des RFC ne semble le dire explicitement, alors ils pourraient légitimement simplement afficher un message d'erreur générique à la place.
Une alternative possible (si vous ne voulez pas utiliser une réponse 200 comme tout le monde semble le faire) serait d'utiliser un code d'état 403 Forbidden . Il s'agit d'un code de réponse largement utilisé et, autant que je sache, presque tous les agents utilisateurs interactifs (c'est-à-dire les navigateurs, par opposition aux moteurs de recherche ou aux gestionnaires de téléchargement) doivent réagir en présentant le contenu à l'utilisateur, - du moins si c'est assez long .
Bien que la description du code d'état 403 indique que "[l '] autorisation ne servira à rien", il convient de comprendre l'OMI dans son contexte comme faisant référence à l'authentification RFC 2617 ou à des mécanismes d'autorisation similaires au niveau du protocole; en ce qui concerne le navigateur, il ne sait pas si le fait de soumettre un formulaire et de recevoir un cookie en réponse compte comme une "autorisation" ou quelque chose d'autre.
Un mécanisme plus couramment utilisé serait de répondre aux demandes non authentifiées avec un redirection temporaire vers une page de connexion distincte, l'adresse URL d'origine étant transmise en tant que paramètre afin que l'utilisateur puisse y être redirigé une fois l'authentification réussie. . Cependant, notez qu'une implémentation naïve pourrait permettre à une personne mal intentionnée de créer un lien de connexion redirigeant l'utilisateur vers une URL arbitraire après la connexion. S'il s'agit d'un problème de sécurité, vous devez prendre des mesures pour l'empêcher, par exemple. en acceptant uniquement les URL de retour correspondant à un modèle sécurisé connu, ou en protégeant l'URL de retour avec un code d'authentification de message pour empêcher toute modification.
Dans tous les cas, si vous utilisez des cookies HTTP pour stocker des jetons d'authentification après la connexion, vous devez inclure un en-tête Vary dans vos réponses (à la fois avant et après l'authentification) afin d'empêcher la mise en cache inappropriée, comme dans Vary: Cookie.
Tout d'abord, si la page a besoin d'une connexion, vous devriez probablement la bloquer avec un fichier robots.txt
Deuxièmement, si les robots atteignent la page, une erreur 401 est appropriée.
probablement, les codes de statut peuvent être utiles pour les non-humains [et pour certains navigateurs? ]
indépendamment par la méthode de connexion, l'en-tête correct doit être envoyé
par exemple, à l'avenir, vous devrez peut-être écrire un client wrapper (pas un navigateur Web) qui s'authentifiera simplement en demandant les en-têtes de page, et non la totalité du code html.
vous pouvez implémenter votre application de connexion avec les deux méthodes en utilisant la même base de données que la liste d'utilisateurs