J'ai un site Web php fonctionnant sous IIS 7.5. Le site est sécurisé par l'authentification Windows et cela fonctionne très bien:
Lorsque les utilisateurs se rendent sur le site, il leur est demandé de saisir un nom d'utilisateur / mot de passe et de passer s'ils sont authentifiés. Si les utilisateurs cliquent sur Annuler ou tapent le mot de passe 3 fois, la page d'erreur 401 s'affiche:
Maintenant, je voudrais afficher une page personnalisée expliquant comment se connecter. Je vais donc aux pages d'erreur, sélectionnez le code d'état 401.2 et le pointe vers la page que je souhaite afficher:
Assurez-vous ensuite que les erreurs personnalisées sont activées pour tout le monde. Et kaa-boom! L'authentification ne fonctionne plus, les utilisateurs ne reçoivent pas d'invite de mot de passe. Comme le dit la documentation, l'authentification Windows fonctionne en envoyant d'abord une réponse 401, puis le navigateur demande à l'utilisateur de fournir les informations d'identification du fournisseur, puis il détermine ce qu'il doit faire ensuite.
Que se passe-t-il ici: à la première demande de la page, IIS essaie d'envoyer un en-tête 401, mais remarque que web.config indique "sur la redirection 401 vers cette page". Et au lieu de l'authentification, cela donne juste la page de redirection.
J'ai essayé de remplacer 401, 401.1, 401.2 - cela n'a fait aucune différence.
Que fais-je de mal et comment donner une page personnalisée sur l'erreur d'authentification de l'utilisateur?
ps Voici le web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpErrors errorMode="Custom">
<remove statusCode="500" subStatusCode="-1" />
<remove statusCode="404" subStatusCode="-1" />
<remove statusCode="401" subStatusCode="-1" />
<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />
<error statusCode="404" prefixLanguageFilePath="" path="/not_restricted/404.htm" responseMode="ExecuteURL" />
</httpErrors>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
</system.webServer>
<system.web>
<identity impersonate="false" />
<customErrors defaultRedirect="http://www.myserver.com/not_restricted/500.htm" mode="Off">
</customErrors>
</system.web>
</configuration>
J'ai rencontré ce même problème: les utilisateurs ne sont pas invités à fournir des informations d'identification après avoir ajouté des httperrors personnalisés et j'ai pu le corriger avec un sous-statut de 0. J'espère que cela aide quelqu'un.
la source
J'ai donc eu du mal avec exactement le même problème d'authentification de base ne demandant pas au navigateur. Ni forcer une erreur personnalisée de 401.0 (c'est-à-dire définir explicitement le sous-code à 0) ni définir la création de la clé de registre ne l'a résolu pour moi.
Il s'est avéré que c'était notre utilisation de pages d'erreur personnalisées pour commencer. En les désactivant, tout fonctionnait bien, de nouveau sous tension ... en particulier les erreurs 401 (0) et 401.2 ont empêché l'invite.
La définition du type d'erreur personnalisé sur «Fichier» dans «ExecuteURL» l'a résolu, mais si l'utilisateur a annulé l'invite ou entré un mauvais mot de passe, il a obtenu un générique «Vous n'avez pas l'autorisation d'afficher ce répertoire ou cette page».
Après avoir obtenu de nombreux conseils à partir de divers articles, mais jamais un "comment" ni un "pourquoi" exacts ... J'utilisais un chemin relatif pour le fichier d'erreur personnalisé qui se trouvait dans un sous-répertoire du site. La modification du chemin d'accès en un chemin absolu a entraîné le remplacement de l'erreur générique ci-dessus par "impossible d'afficher cette page" en cas d'annulation ou de mauvais mot de passe. Un peu plus en creusant et j'ai trouvé un postparler d'un attribut de configuration "allowAbsolutePathsWhenDelegated" qui est défini sur false par défaut. Il indique également que si vous placez simplement le fichier d'erreur client dans la racine de votre site, puis dans l'emplacement d'erreur personnalisé uniquement le nom du fichier (c'est-à-dire le chemin relatif vers la racine du site), cela fonctionnerait ... , Je ne voulais pas mettre d'erreurs personnalisées à la racine de mon site. J'ai donc utilisé ConfigurationEditor pour définir l'attribut ci-dessus sur true, définir le chemin absolu vers les fichiers d'erreur personnalisés et tout a commencé à fonctionner correctement. L'invite est restée, une erreur personnalisée s'affiche lorsqu'elle est déclenchée.
Ce que je voudrais, c'est pouvoir utiliser l'attribut File avec un chemin relatif imbriqué, mais jusqu'à présent, je n'ai pas découvert pourquoi je ne peux pas ou comment le faire. L'autre question est, si en utilisant un chemin absolu, si je crée potentiellement un trou de sécurité (c'est-à-dire pourquoi cela serait-il désactivé par défaut?)
Quoi qu'il en soit, j'espère que cela aide quelqu'un.
la source
Pour une raison étrange, dans mon cas, une combinaison de 2 solutions a fonctionné pour moi pour asp.net MVC 5.
la source