IIS7: HTTP-> HTTPS proprement

Existe-t-il un moyen propre de rediriger toutes les tentatives d'accès à une version HTTP: // d'un site vers son équivalent HTTPS: //?

Je pense que la manière la plus propre est celle décrite ici sur IIS-aid.com . C'est web.config uniquement et donc si vous changez de serveur, vous n'avez pas à vous souvenir de toutes les étapes que vous avez suivies avec la page d'erreur personnalisée 403.4 ou d'autres autorisations spéciales, cela fonctionne simplement.

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="HTTP to HTTPS redirect" stopProcessing="true">
          <match url="(.*)" />
            <conditions>
              <add input="{HTTPS}" pattern="off" ignoreCase="true" />
            </conditions>
            <action type="Redirect" redirectType="Permanent" url="https://{HTTP_HOST}/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

La solution la plus simple et la plus propre que j'ai trouvée était de

1. Dans les paramètres SSL -> exiger SSL

2. Dans les pages d'erreur -> Sur l'erreur 403.4 -> Redirection vers le site HTTPS

3. Dans les pages d'erreur -> Modifier les paramètres des fonctionnalités ... -> Définir les erreurs détaillées pour les demandes locales et les pages d'erreur personnalisées pour les demandes distantes

L'avantage est qu'il ne nécessite aucune ligne de code supplémentaire. L'inconvénient est qu'il vous redirige vers une URL absolue.

Une manière propre ne change que le schéma d'URL de http -> https et laisse tout le reste équivalent. Il doit être côté serveur afin qu'il n'y ait pas de problèmes de navigateur.

JPPinto.com a des instructions étape par étape sur la façon de procéder, sauf qu'ils utilisent javascript (HttpRedirect.htm) au lieu d'une redirection côté serveur. Pour une raison quelconque, je n'ai pas pu obtenir IE exécuter le javascript si vous avez activé `` Afficher les messages d'erreur HTTP conviviaux '', ce qui est activé par défaut. Une autre chose avec le script est que la redirection vers le chemin ne fonctionnait pas même dans FF ou Chrome. Le script redirige toujours vers root. (J'ai peut-être manqué quelque chose, car il devrait rediriger vers le chemin.)

Pour ces raisons, j'ai utilisé une page ASP pour la redirection. L'inconvénient est bien sûr que cela nécessite l'activation de l'ASP classique sur le serveur.

OpsanBlog a un script ASP et des instructions qui fonctionnent bien avec IIS6.

J'ai eu quelques problèmes en utilisant cette méthode avec IIS7. L'interface utilisateur pose principalement des problèmes, car IIS7 permet de rater quelque chose très facilement.

• Tout d'abord, vous devez installer ASP en tant que fonctionnalité de rôle de serveur Web.
• Deuxièmement, l'utilisation d'un répertoire virtuel ne fonctionnait pas comme prévu dans IIS7 et je n'ai pas essayé de déboguer cela. Au lieu de cela, j'ai mis le fichier dans le dossier racine du site et utilisé l'url '/SSLRedirect.asp' dans la page d'erreur 403.4 pour le référencer.
• Enfin, la partie la plus délicate, vous ne devez PAS appliquer SSL pour SSLRedirect.asp . Sinon, vous obtiendrez une erreur 403.4. Pour ce faire, sélectionnez le fichier dans IIS7 «Affichage du contenu» et passez à «Affichage des fonctionnalités» afin de pouvoir modifier les paramètres SSL pour le fichier unique et désactiver la case à cocher «Exiger SSL».

Le gestionnaire IIS doit afficher le nom du fichier dans l'en-tête.

Global.asax

protected void Application_BeginRequest()
{
if (!Context.Request.Url.AbsoluteUri.Contains("localhost") && !Context.Request.IsSecureConnection)
Response.Redirect(Context.Request.Url.ToString().Replace("http:", "https:"));
}

J'utilise asp classique (intranet) et sur les pages qui nécessitent une connexion, le fichier d'inclusion de connexion effectue la redirection:

if Request.ServerVariables("SERVER_PORT_SECURE") <> "1" or Request.ServerVariables("HTTPS") <> "on" then 
    Response.Redirect "https://" & Request.ServerVariables("SERVER_NAME") & Request.ServerVariables("URL")
end if

Cela n'inclut bien sûr pas les données GET ou POST. Donc, en fait, c'est une redirection propre vers votre page sécurisée.

Je pense que par «proprement», vous voulez dire comme avec une redirection 300. Config pour beaucoup de serveurs et de langues ici .