2009-02-27 18 views
24

ho bisogno di memorizzare una serie di informazioni di configurazione in PHP.Qual è il modo migliore per memorizzare le variabili di configurazione in PHP?

ho preso in considerazione la seguente ....

// 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'; 
}  

Questo è tutto quello che ho pensato finora. Intendo importare queste informazioni di configurazione nella mia applicazione con require /config.inc.php.

Che cosa funziona per voi per quanto riguarda la memorizzazione dei dati di configurazione e quali sono le migliori pratiche in merito?

risposta

7

Sono sempre andato con l'opzione n. 2 e mi assicuro che nessuno tranne il proprietario abbia accesso ad esso. È il metodo più popolare tra le applicazioni PHP come Joomla, vBulletin, Gallery e numerosi altri.

Il primo metodo è troppo disordinato per me (leggibilità) e il terzo è troppo pericoloso da fare. Non ho mai pensato al metodo Class, quindi qualcun altro può fornire il proprio input su quello. Ma suppongo che vada bene fino a quando l'accesso corretto viene usato sull'uso della classe.


Esempio ..

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

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

Ora questo esempio di codice è veramente stupido, ma solo un esempio. Considera cosa potrebbe essere restituito dalla funzione a seconda dello scenario che l'utente potrebbe provare a utilizzare nel proprio input.

Lo scenario 2 causerebbe un problema solo se lo si è reso globale all'interno della funzione. Altrimenti è fuori ambito e irraggiungibile.

+0

È pericoloso nel modo in cui se qualche input utente viene fornito con MYSQL_PASSWORD, potrebbe essere passato con la password effettiva? – alex

+0

Questo sarebbe ciò che potrebbe accadere se segui il secondo metodo che hai elencato. Lo imposta essenzialmente come variabile globale, visibile in qualsiasi ambito. è possibile scegliere come classi o funzioni possono accedere alla matrice $ config, in modo fino a quando non lo avete visibile nel campo di applicazione sbagliata, si dovrebbe andare bene. –

+0

Post modificato per fornire un esempio su due diversi modi in cui è possibile definire elementi nel codice e in che modo l'utente può ottenere le informazioni. –

1

Generalmente utilizzo il secondo metodo ... Quando si gestiscono connessioni di database, in genere apro una connessione all'inizio della richiesta, quindi la chiudo alla fine. Ho una funzione che stabilisce la connessione, quindi rimuove il nome utente/password dalla matrice globale (con la funzione unset()), questo impedisce altre parti del sistema di accedere ai dati di connessione mysql "sensibili".

0

Sono anche con l'opzione 2 per la maggior parte dei valori di configurazione. Se erano andando a implementare la classe quindi vorrei legare i valori specifici per la classe che colpisce invece di una classe generale di configurazione.

Nel tuo esempio, la tua Classe sarebbe per le connessioni al database e un'istanza salverà la password, nome_db, ecc. Ciò incapsulerebbe i dati correttamente e fornirà anche un modo semplice per creare più connessioni se ciò è mai stato necessario.

+0

Sì, è vero, tranne quando si desidera modificare un file per poter modificare qualsiasi dato di configurazione, quindi le costanti collegate a una classe Db renderanno più difficile di un singolo punto di accesso (che è quello che voglio) – alex

4

Direi che dipende anche della base di utenti un po '. Se le configurazioni devono essere molto user friendly o l'utente deve avere la possibilità di cambiare la configurazione via web ecc.

Io uso Zend Config Ini per questo e altre impostazioni sono memorizzate nel DB SQL.

+0

Mai sentito parlare di quel metodo prima. Buono a sapersi! –

Problemi correlati