Re: sobre Joomla! y un nuevo café

[Rodrigo Fuentealba]

El día 5 de marzo de 2009 13:42, Baronti <baronti en gmail.com> escribió:
>
> Me parece que quien lo escribio (el mensaje inicial) no tiene mucha
> idea de como funciona joomla globalmente.

Lo reconozco, no lo uso y por ende no me interesa. Prefiero mantenerme
alejado del monstruito.

> 1° la carpeta includes que es en donde se definen todas las clases no
> debe tener permisos de escritura por lo que instales lo que instales
> no te debe alterar las clases.

El que no tenga permisos de escritura no me permite sobreescribir el
archivo, pero sí me permite sobreescribir "la clase".

// /directorio/clase.php (chmod 444)
<?php

    class MiClase
    {
        var $password;
    }

?>

// clase.pub.php (chmod cualquiercosa)
<?php

    require_once('/directorio/clase.php');

    class MiClase2 extends MiClase
    {
        public function __construct()
        {
            parent::_construct();
            echo $password;
        }
    }

?>

Eso significa extender la clase para sobreescribir el método de
construcción. El archivo permanece inalterable, y con permisos de sólo
lectura. Si le quitas el permiso de sólo lectura y lo dejas ilegible,
plop!!! no funciona nada, ni lo bueno ni lo malo.

En mi código, uso algo así:

<?php

    class MiClaseUnPocoMasSegura
    {
        private $password = 'mipassword';
    }

    class MiClaseQueExtiende extends MiClaseUnPocoMasSegura
    {
        public function __construct()
        {
             echo $this->password;
        }
    }

    $c = new MiClaseQueExtiende();

?>

Ouch, eso no te devuelve nada. No sabes cómo obtener una contraseña.

> 2° la forma en que esta declarada la clase database es especialmente
> útil para aquellos que desarrollamos funciones de interconectividad
> con otras bases de datos, por ejemplo validar usuarios en joomla que
> son tomados de un servidor SQL Server, o generar en joomla el reporte
> de ventas que es tomado de un servidor Oracle, etc. Es simple, segura
> y sobre todo ahora docenas de horas al hacer inteconexiones.

Utilidad no implica seguridad.

> 3° Hacer funciones para que valide nombre de usuario, contraseña,
> servidor mysql, base de datos, etc. en teoría es lo ideal ya que no
> harian uso de conexiones persistentes lo que incrementa la seguridad,
> en la práctica hacerlo de esa forma ralentiza de forma exponencial el
> rendimiento de cualquier sitio, el tiempo de ejecución en el servidor
> se incrementa, por lo que sitios que tengan solo unos cuantos cientos
> de visitas por día simplemente colapsarían a no ser de que se instalen
> en un servidor dedicado.

Oh, cierto, y Symfony con sfGuardPlugin exactamente hace eso y Yahoo!
lo usa para muchas cosas.

Sí, lo sé, es un argumento de flojos, pero la verdad es que me da una
flojera enorme argumentar con detalle por qué es una mala práctica.
Tal vez debieran mirar a Doctrine para hacer sus funciones de bases de
datos, o Propel (aunque este último proyecto está a medio morir
saltando).

> 4° "Hackear" un sitio por medio de un módulo que extienda la clase
> database, el concepto es verdaderamente ridículo, ya que la mayoría de
> los módulos (solo para aclarar, son los cuadritos que aparecen en los
> lados como encuestas, login, etc) estan escritos en simple
> HTML-Javascript y el archivo con los detalles en XML. aquellos que
> incluyen php es únicamente para hacer consultas a la base de datos.

Por eso mismo es que yo puedo hacer un módulo para hacer estragos. Un
módulo "puede" incluir PHP, y queda a conciencia del personaje que
escribe el módulo si es que lo usa para hacer el bien o el mal.

> 6° Finalmente existe una diferencia abismal entre el término Hacker y
> el término Cracker, sugiero que busque en wikipedia el significado de
> ambos.

Yawn. Qué flojera.

-- 
Rodrigo Fuentealba
http://www.thecodekeeper.net/