Dois-je retourner un code d'état http 401 sur un formulaire de connexion basé sur html?

Dois-je retourner un code d'état http 401 sur un formulaire de connexion basé sur html? La page est un formulaire de connexion dédié et n'a pas d'autre contenu significatif, juste un cadre de site. L'URL peut cependant être pour une page qui a un contenu significatif, mais nécessite une connexion. Notez que cette configuration renvoie uniquement le code d'état 401 et ne demande pas à l'utilisateur une authentification 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 connu ni entendu parler de conséquences néfastes de le faire.

Lors de l'envoi de 401, "la réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 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 existe des moyens de contourner les moteurs de recherche pour les convaincre d'indexer ou non les pages en fonction de la présence d'un formulaire de connexion, mais je préfère utiliser les codes de statut http, en particulier 401 car sa définition semble être un match parfait sinon pour l'exigence d'en-tête WWW-Authenticate.

Y a-t-il une raison pour laquelle je ne devrais pas utiliser 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 juste pour la facilité de ne pas l'implémenter au niveau de l'application?

Comme vous le notez, la 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 faux en-tête comme:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

mais je n'ai aucune idée de ce que les navigateurs feront s'ils reçoivent 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 demande à l'utilisateur (comme RFC 2616 dit qu'ils devraient faire si l'authentification échoue), mais aucun RFC ne semble le dire explicitement, de sorte qu'ils pourraient légitimement afficher un message d'erreur générique au lieu.

Une alternative possible (si vous ne voulez pas simplement utiliser une réponse 200 comme tout le monde semble le faire) serait d'utiliser un code d'état interdit 403 . Il s'agit d'un code de réponse largement utilisé et, à ma connaissance, presque tous les agents utilisateurs interactifs (c'est-à-dire les navigateurs, par exemple les moteurs de recherche ou les gestionnaires de téléchargement) devraient y réagir en présentant le contenu à l'utilisateur, au moins si c'est assez long .

Bien que la description du code d'état 403 indique que "[une] autorisation ne sera pas utile", cela devrait être compris dans le contexte de l'OMI comme faisant référence à l'authentification RFC 2617 ou à des mécanismes d'autorisation de niveau protocole similaires; en ce qui concerne le navigateur, il n'a aucune idée si l'envoi d'un formulaire et la réception d'un cookie en réponse comptent comme une «autorisation» ou autre chose.

Un mécanisme plus couramment utilisé serait de répondre aux demandes non authentifiées par une redirection temporaire vers une page de connexion distincte, avec l'URL d'origine passée en paramètre afin que l'utilisateur puisse y être redirigé après une authentification réussie. Cependant, notez qu'une implémentation naïve pourrait permettre à une personne malveillante de créer un lien de connexion qui redirigerait l'utilisateur vers une URL arbitraire après la connexion. Si cela peut être un problème de sécurité, vous devez prendre des mesures pour l'empêcher, par exemple en acceptant uniquement renvoyer les URL 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 (avant et après l'authentification) pour éviter une 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 par robots.txt

Deuxièmement, si les robots atteignent la page, une erreur 401 est appropriée.

probablement, les codes d'état 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