Ignorer les répertoires .svn sous IIS

Nous sommes une organisation de développement Web et nous avons récemment décidé d'utiliser Subversion pour notre système de contrôle de version. Étant donné que l'exécution d'une mise à jour est beaucoup plus rapide que d'exporter et de copier les fichiers, les développeurs souhaitent pouvoir faire du serveur de production une copie de travail.

La seule préoccupation que j'ai à ce sujet est tous les fichiers .svn éparpillés à travers le système, et le fait qu'une personne entreprenante pourrait, potentiellement, lire le contenu des fichiers là-dedans, leur donnant éventuellement des informations que nous préférerions ne pas avoir .

Quelle est la meilleure façon / la plus simple d'empêcher IIS de diffuser du contenu à partir de ces répertoires .svn?

"Ne fais pas comme ça" ne répond pas à la question.

En pratique, j'aime avoir une copie de travail sur le serveur de production, car de cette façon, je peux faire des changements rapides dans la production (qui ne l'a jamais fait?) Et les archiver à nouveau. Cela dépend de l'endroit où vous voulez votre curseur de sécurité / commodité, et dans de nombreux cas, c'est un bon endroit.

La solution standard dans Apacheland consiste à y laisser les fichiers .svn mais à dire au serveur Web de ne jamais les servir. Voici comment procéder avec IIS 5-7 sous Windows 2000-2008.

1. Téléchargez et installez ISAPI_Rewrite - la version Lite sera suffisante à cet effet. Notez la configuration système supplémentaire requise pour Win 2008. Avertissement - le programme d'installation MSI arrête et démarre IIS.

2. Décochez la case "lecture seule" des propriétés du fichier httpd.ini . Si vous avez utilisé le programme d'installation MSI, il existe un raccourci vers le fichier httpd.ini dans le menu Démarrer sous Helicon-> ISAPI_Rewrite

3. Ajoutez ces lignes à httpd.ini :

Directives ISAPI_Rewrite dans httpd.ini :

# Deny access to Subversion working copy administrative
#  directories (.svn) and their contents
RewriteRule .*/\.svn\b.* . [F,I,O]

Désormais, toute demande de répertoire .svn ou de son contenu entraînera un 404 Not Found du serveur.

Vous pouvez vous assurer que tous les comptes d'utilisateurs utilisés par IIS ne disposent pas des droits d'accès aux répertoires .svn.

Vous pouvez le faire manuellement (non recommandé) ou utiliser quelque chose comme le script de suppression MrJangles, déclenché pour s'exécuter après avoir effectué la mise à jour SVN ou exécuté régulièrement en tant que tâche planifiée:

for /r YOURPATH %f in (.svn) do icacls /deny <name_of_iis_user>:F "%f"

(note: je n'ai pas testé ce qui précède, vous devrez vérifier qu'il fait ce qu'il essaie avant de compter dessus en production, voir la sortie de "icacls / help" pour plus d'informations)

(une autre note: "icacls" est une commande Vista / 2008, sur les versions antérieures de Windows la commande est "cacls" à la place)

À l'aide d'IIS 7, ouvrez le Gestionnaire des services Internet, sélectionnez le nœud du serveur, double-cliquez sur la fonctionnalité Mappages de gestionnaires . Cliquez sur l'action Ajouter un gestionnaire géré et configurez le gestionnaire comme suit:

• Chemin de demande: * .svn / * (mappage générique pour tous les fichiers dans tous les dossiers .svn)
• Type: System.Web.HttpForbiddenHandler
• Nom: Subversion-metadata (vous pouvez choisir un nom différent si vous le souhaitez)

Maintenant, toute demande de fichiers dans les dossiers de métadonnées Subversion nommés .svn dans tous les sites doit retourner ceci:

Erreur serveur dans l'application '/'

Ce type de page n'est pas diffusé.

Description: Le type de page que vous avez demandé n'est pas diffusé car il a été explicitement interdit. Veuillez vérifier l'URL ci-dessous et assurez-vous qu'elle est correctement orthographiée.

URL demandée: /.svn/text-base/Default.aspx.svn-base

Vous pouvez choisir un type de gestionnaire différent si vous le souhaitez, peut-être un gestionnaire FileNotFound qui renverra un code d'état 404.

Pour IIS 6 (avec ASP.NET 2 installé et configuré):

Naviguez vers le répertoire d'accueil> Configuration> Mappage et mappez l' .svn-baseextension vers %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll. Ensuite, dans machine.config (que vous pouvez trouver dans %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG), vous pouvez ajouter le même gestionnaire que ci-dessus pour l'extension, ajouter l'élément XML suivant en tant qu'enfant de l' <httpHandlers>élément -element:

<add verb="*" path="*.svn-base" type="System.Web.HttpForbiddenHandler"/>

Cela empêchera uniquement les visiteurs de demander les fichiers de code source, ils pourraient toujours demander d'autres fichiers à partir des dossiers .svn. Mappez plus d'extensions vers aspnet_isapi.dll ou effectuez un mappage générique (cela affectera les performances) et vous pourriez bloquer la demande de plus de fichiers.

Du point de vue de la sécurité, je rééduquerais vos développeurs.

La facilité de déploiement n'est pas nécessairement une bonne idée si vous sacrifiez la sécurité.

Vous prévoyez une configuration pour bloquer l'accès aux informations sensibles. Que se passe-t-il si la configuration change accidentellement. Que se passe-t-il si un correctif IIS tombe en panne et modifie le fonctionnement de votre configuration. Que se passe-t-il si la bibliothèque tierce que vous utilisez tombe en panne et cesse de fonctionner. Je peux penser à plusieurs événements extrêmement probables qui briseraient votre configuration et permettraient d'accéder à ces fichiers, ce qui serait TOTALEMENT ATTÉNUÉ en n'ayant pas les fichiers sur le serveur en premier lieu.

Vous devez créer un script de déploiement qui copie les fichiers appropriés à partir d'un serveur de transfert. Vous pouvez même passer via SVN dans un répertoire différent sur Prod.

Pour déployer, vous pouvez utiliser RoboCopy et la commande / XD pour exclure les répertoires .svn. Vous pouvez utiliser l'outil de déploiement Web Microsoft et limiter les répertoires avec cela. Vous pouvez déployer et exécuter ce qui précède for /r YOURPATH %f in (.svn) do rd /s /q "%f"si vous en avez également besoin.

Ne déployez simplement pas ces répertoires sur le site Web de production.

N'utilisez pas la subversion. Sérieusement.

D'après vos commentaires, il semble que vous utilisez le mauvais outil pour le travail. Subversion est un excellent outil pour vos développeurs, mais ce n'est pas un outil de déploiement / mise en miroir. Si votre objectif est de simplement copier des fichiers de votre serveur de test / test vers votre serveur de production avec un minimum de bande passante et de temps, alors je vous suggère d'utiliser rsync . Maintenant, puisque je suis un administrateur Unix, il peut y avoir un équivalent de Windows à rsync que je ne connais pas, vous pouvez donc faire des recherches. Cependant, vous pouvez utiliser rsync sous Cygwin ou cwrsync .

Rsync vous permet de mettre en miroir des répertoires sur un serveur avec des répertoires sur un autre. Il calcule un delta entre les deux serveurs et copie uniquement les différences. Non seulement cela, mais il comprime le delta et, éventuellement, peut également le chiffrer.

La meilleure pratique serait un système de déploiement automatique qui exporte et publie après une mise à jour SVN. Prenons l'exemple d'Hudson. Il y en a quelques autres, mais comme nous n'en avons pas besoin, je ne suis pas très bien informé

Greetz, GHad

Je programme un script sur mes serveurs de production qui recherche .svn et supprime simplement les fichiers. Je ne pense pas que cela fonctionnera dans votre cas.

for /r YOURPATH %f in (.svn) do rd /s /q "%f"

Si la suppression des fichiers n'est pas une option, vous pouvez mettre la sécurité de base sur les répertoires via IIS (mot de passe ou restrictions IP). Cela empêcherait IIS de diffuser du contenu à des utilisateurs non autorisés.

Bonne chance!