buddy - php deployment
Desplegar un repositorio de Mercurial para la producción-Preocupaciones de seguridad y consejos (3)
En mi investigación, encontré cierta preocupación sobre la implementación de una aplicación PHP en línea mientras dejaba su carpeta ".hg" o carpetas ".svn" en su lugar en el servidor de producción. Desafortunadamente, no pude encontrar una explicación clara de por qué esto es una preocupación. Me gustaría entender mejor este riesgo de seguridad.
Me parece que no desea que estas carpetas sean visibles más de lo que desea que se muestren los contenidos de los archivos PHP. ¿No sería la solución configurar el servidor web para que no sirva al directorio ".hg"? ¿La preocupación por la seguridad es más profunda que esto? Realmente no lo sé ¡Su ayuda con esto es muy apreciada!
Si es útil, la razón por la que deseo mantener el control de la versión en el repositorio de producción del servidor es la siguiente:
- Implementación más rápida desde etapas (frente a hacer una copia nueva por implementación)
- Capacidad de reversión fácil y rápida
- La capacidad de verificar que la producción se mantenga sin cambios (a través de
hg st)
Las alternativas son bienvenidas.
¡Gracias!
Aparte del riesgo de que los archivos de diff se sirvan accidentalmente al cliente, no veo ningún otro problema de seguridad.
Teniendo en cuenta que restringe el acceso a .svn, .hg u otro. El hecho de que tenga esas carpetas allí implica que tendrá que aplicarles constantemente la restricción, lo cual es arriesgado. Los errores humanos suceden
Saludos, Alin
Soy fan de que mi DocumentRoot sea un clon de mi repositorio mercurial. De hecho, incluso puede configurar ese repo para actualizar automáticamente en push usando un gancho como este:
[hooks]
changegroup = hg update
Lo que significa que puede hg push al repositorio en su servidor y obtendrá la descarga del sitio actualizada automáticamente. Muchas personas lo están haciendo.
De hecho, si uno pudiera confiar en no servir a los directorios .svn / .hg de manera predeterminada, no sería un problema. Tal como está, alguien (newbee / nuevo desarrollo / experimentado en un mal día) hace un pequeño cambio que destruye esos ajustes, y como ''no pasa nada'' no se da cuenta de que la protección se ha ido. Voilà, tu código fuente abierto al mundo, con posiblemente incluso contraseñas y secretos almacenados. No es que algo salga mal con la configuración adecuada, es que con una alteración menor, fácilmente minimizada, podrían salir mal, entonces ¿por qué no ir a lo seguro?
En un proceso de liberación estrictamente controlado, me resulta más fácil export ciertas ramas / etiquetas a ciertas carpetas, y un cambio a una nueva etiqueta / branche que ha sobrevivido a las pruebas simplemente está cambiando la raíz del documento desde /path/project/release-123 a /path/project/release-124 (haciendo que sea tan fácil, incluso más rápido, volver a la release-123 puede que sea necesario). Si tiene un proceso de lanzamiento con más cambios pequeños y correcciones de errores, trabajar con exportaciones puede ser realmente doloroso, pero la seguridad adicional lo vale, en mi opinión.
En los servidores de desarrollo, todo ya está filtrado en (VPN-) IPs o certificados, por lo que utilizo un checkout con la versión troncal ''más reciente y mejor'' con los directorios de control de versiones sin ningún problema.
editar:
Tanto Mercurial como Subversion hoy en día mantienen los datos en un único directorio .hg / .svn en el nivel superior. Como uno normalmente haría un checkout donde la mayoría de los archivos están fuera de la raíz del documento (y la raíz del documento es probablemente un subdirectorio más abajo), está bien . Solo asegúrese de que sus directorios de control de versiones no se encuentren en una carpeta alcanzable para el servidor web dentro de la raíz del documento, y puede mantener los pagos en lugar de exportarlos sin muchos problemas.