Ha habido un RP para eliminar los archivos index.html, pero nunca se aplicó. ¿Porqué es eso?
Siento que este es un escenario de "caso límite". Una gran parte de los usuarios de Joomla estaría segura sin estos archivos, pero algunas personas ejecutan Joomla en un host mal configurado (y algunos en un host mal configurado que no les permitirá reconfigurar) que mostraría el contenido del directorio si el directorio fuera pedido. Este archivo evita eso.
A nivel personal, si no necesita los archivos, es innecesaria la hinchazón en el cms y puede eliminarlos.
A nivel de CMS, creo que resuelve un problema que puede tener problemas de seguridad importantes con una hinchazón relativamente menor. (Los archivos generalmente están vacíos o contienen una pequeña línea de html).
No puedo hablar de la razón exacta por la que el RP no fue aceptado (ya que ni siquiera tengo ese poder, mucho menos chatear con las personas que sí lo tienen); Creo que el beneficio relativo para la comunidad supera la hinchazón.
Dicho esto, hay un método alternativo que he oído mencionar en algunos eventos de Joomla acerca de mover la mayoría de los archivos "a un nivel superior". La idea es obtener todos los archivos sobre el public_htmldirectorio para que no se pueda acceder a los archivos directamente. Solo querrá que el index.phparchivo, el .htaccessarchivo y las carpetas imagesy mediaestén accesibles en la web (para mantener accesibles su CSS, JS e imágenes).
En este punto, confía menos en la configuración de un servidor base y puede garantizar más que no se accederá a los archivos de manera inapropiada. Esto tendría sus propios problemas de configuración (ya que ahora necesitamos acceder a los archivos por encima de nuestra "raíz").
Con todo, no estoy seguro de que haya un plan más infalible para mantener a las personas seguras sin muchos problemas que el uso de index.htmlarchivos. Entonces, si estaba lanzando una plataforma en general, me quedaría con los index.htmlarchivos.
La razón de un index.html en cada carpeta es protegerlo para revelar información sobre un entorno de alojamiento mal configurado.
Si este es un problema real y los cms lo consideran, esa es otra pregunta.
Que yo sepa, nunca hubo un RP para eso. Hay un rastreador de características ( http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30192 ) que está "listo para su revisión". El parche solo existe en una rama y no es un RP. Por lo tanto, esta es probablemente la razón por la que nunca se fusionó.
¿O te refieres a otro PR?
fuente