Acabo de pasar una noche divertida haciendo algunos cambios en uno de nuestros servidores de Windows, la actualización fue para agregar una gran funcionalidad nueva a nuestro panel de control (DotNetPanel) y también para asegurarme de que el servidor estuviera completamente actualizado.

La actualización comenzó genial, instala software y el reinicio obligatorio que MS te obliga a hacer (Siempre es un momento de infarto). La máquina volvió y todo se veía bien al principio. Fui a probar algunos de los sitios en el servidor y todo parecía estar bien hasta que probé mi propio blog y me di cuenta de que por alguna razón los enlaces permanentes no funcionaban correctamente. Una revisión rápida de algunos otros blogs y el mismo trato, los enlaces permanentes basados ​​en PATHINFO (enlaces que incluyen una ruta /index.php/) fueron FUBARed simplemente devolviendo un error 404. :(

La primera verificación fueron los permisos de archivo, ya que esto puede ser una causa común de errores de PHP, nada de lo que intenté marcó la diferencia, luego fue verificar la configuración de PHP.ini, no, no ayudó, luego fue IIS, no había nada malo allí, luego fue mi navegador , tal vez algo anda mal con las cookies o la caché…. nop. Estaba perplejo ... ... muchas comprobaciones y nuevas comprobaciones más tarde y todavía no podía entender por qué los enlaces permanentes no funcionaban ... Varias horas después y casi me rindo, un informe de un sitio de Magento que tiene problemas para acceder a su administrador (Sí, escuchó que Magento funciona correctamente en nuestro servidor de Windows: 0), o al menos había estado activo hasta hace unas horas. ).

Se fue a verificar por qué y notó una similitud con el problema de WordPress, el administrador de Magento también usa URL con /index.php/ y, aunque estaban siendo redirigidos a la página de inicio en lugar de mostrar un 404, seguía siendo una coincidencia ...

Ahora, estos sitios estaban en procesos y rutas de IIS completamente separados, por lo que los permisos y IIS parecían un callejón sin salida, por lo que aún no sabía que era un problema de todo el servidor no localizado en una ruta específica.

Después de más horas de rascarme la cabeza, decidí revisar las nuevas funciones que había instalado para ver si algo allí podría haber causado un problema tan extraño, con la actualización obtuvimos algunas nuevas herramientas de seguridad, una de ellas es la nueva herramienta URLSCAN de Microsoft. que tiene varios beneficios de seguridad, me di cuenta de que tal vez esto tuviera algo que ver con el problema, por lo general, esperaría que estas cosas se instalen deshabilitadas hasta que esté listo para habilitarlas.

Bueno, para cortar una experiencia larga y agotadora, URLSCAN corto fue habilitado y tiene una buena configuración habilitada (o más bien configurada para deshabilitar) de forma predeterminada llamada “AllowDotInPath”…. El nombre lo dice todo realmente y está destinado a bloquear cualquier URL que tenga un punto en la ruta de la URL, configuré esto en 1 "AllowDotInPath = 1" y guardé el INI y de repente todos los sitios de WordPress y Magento volvieron a vida. Gracias por esa MS….

Entonces, después de todo eso, fue una solución tan simple aunque menos que obvia.

De todos modos, estoy escribiendo esto para ayudar a otros administradores, ya que estoy seguro de que esto afectará a muchas otras personas que utilizan este tipo de técnicas de reescritura de URL basadas en PHP PATHINFO en IIS.



Miércoles, Julio 7, 2010

« Atrás