2009-02-27 9 views
24

Necesito almacenar una gran cantidad de información de configuración en PHP.¿Cuál es la mejor manera de almacenar variables de configuración en PHP?

me han considerado los siguientes ....

// Doesn't seem right. 
$mysqlPass = 'password'; 

// Seems slightly better. 
$config = array(
    'mysql_pass' => 'password' 
); 

// Seems dangerous having this data accessible by anything. but it can't be 
// changed via this method. 
define('MYSQL_PASSWORD', 'password'); 

// Don't know if this is such a good idea. 
class Config 
{ 
    const static MYSQL_PASSWORD = 'password'; 
}  

Esto es todo lo que he pensado hasta ahora. Tengo la intención de importar esta información de configuración en mi aplicación con require /config.inc.php.

¿Qué le sirve a usted en cuanto al almacenamiento de los datos de configuración y cuáles son las mejores prácticas al respecto?

Respuesta

7

Siempre me he ido con la opción n. ° 2 y solo me aseguro de que nadie más que el propietario tenga CUALQUIER tipo de acceso. Es el método más popular entre las aplicaciones PHP como Joomla, vBulletin, Gallery y muchas otras.

El primer método es demasiado complicado para mí (legibilidad) y el tercero es MUY peligroso de hacer. Nunca he pensado en el método de clase, por lo que alguien más puede proporcionar su opinión sobre eso. Pero creo que está bien siempre y cuando se use el acceso correcto en el uso de la clase.


Ejemplo ..

define('EXAMPLE1', "test1"); // scenario 1 
$example2 = "test2"; // scenario 2 

function DealWithUserInput($input) 
{ 
    return eval($input); 
} 

Ahora bien, este ejemplo de código es muy tonto, pero sólo un ejemplo. Considere qué podría devolver la función dependiendo de qué escenario el usuario podría tratar de usar en su entrada.

El escenario 2 solo causaría un problema si lo hiciera global dentro de la función. De lo contrario, está fuera del alcance e inalcanzable.

+0

¿Es peligroso que la entrada de algunos usuarios con MYSQL_PASSWORD se convierta en una contraseña real? – alex

+0

Eso sería lo que sucedería si sigues el segundo método que enumeró. En esencia, lo establece como una variable global, visible en cualquier ámbito. Puede elegir cómo las clases o funciones pueden acceder a la matriz $ config, por lo que siempre que no la tenga visible en el ámbito incorrecto, debería estar bien. –

+0

Publicación editada para dar un ejemplo de dos maneras diferentes en que podría haber cosas definidas en su código y cómo el usuario podría obtener la información. –

1

Generalmente utilizo el segundo método ... Al manejar conexiones de bases de datos, generalmente abro una conexión al principio de la solicitud, luego la cierro al final. Tengo una función que establece la conexión, luego quita el nombre de usuario/contraseña de la matriz global (con la función unset()). Esto evita que otras partes del sistema accedan a los datos de conexión "sensibles" de mysql.

0

También estoy con la opción 2 para la mayoría de los valores de configuración. Si fuera va a implementar la Clase, vincularía los valores específicos a la Clase a la que afecta en lugar de una Clase de configuración general.

En su ejemplo, su clase sería para conexiones de bases de datos y una instancia guardaría la contraseña, db_name, etc. Esto encapsularía los datos correctamente y también proporcionaría un medio fácil para crear conexiones múltiples si alguna vez se necesitara.

+0

Sí, eso es cierto, excepto cuando desee editar un archivo para poder cambiar cualquier dato de configuración, entonces las constantes asociadas a una clase Db lo harán más difícil que un solo punto de acceso (que es lo que quiero) – alex

4

Yo diría que también depende un poco de la base de usuarios. Si configuraciones tiene que ser muy fácil de usar o usuario tiene que tener la capacidad de cambiar de configuración vía web, etc.

utilizo Zend Config Ini para este y otros ajustes se almacenan en la base de datos SQL.

+0

Nunca he oído hablar de ese método antes. ¡Bueno saber! –

Cuestiones relacionadas