2009-02-27 18 views
24

Potrzebuję przechowywać kilka informacji konfiguracyjnych w PHP.Jaki jest najlepszy sposób przechowywania zmiennych konfiguracyjnych w PHP?

mam uznać następujące ....

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

To wszystko myślałem tak daleko. Zamierzam zaimportować te informacje konfiguracyjne do mojej aplikacji pod numerem require /config.inc.php.

Co działa dla Ciebie w odniesieniu do przechowywania danych konfiguracyjnych i jakie są najlepsze praktyki w tym zakresie?

Odpowiedz

7

Zawsze korzystałem z opcji nr 2 i zapewniam, że nikt oprócz właściciela nie ma dostępu do niej. Jest to najpopularniejsza metoda wśród aplikacji PHP, takich jak Joomla, vBulletin, Galeria i wiele innych.

Pierwsza metoda jest dla mnie zbyt brudna (czytelność), a trzecia jest zbyt niebezpieczna. Nigdy nie myślałem o metodzie Class, więc ktoś inny może podać swój wkład w tę. Ale wydaje mi się, że jest to w porządku, o ile odpowiedni dostęp jest używany w klasie.


Przykład ..

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

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

Teraz ten przykład kodu jest naprawdę głupie, ale tylko przykład. Zastanów się, co może zostać zwrócone przez funkcję w zależności od tego, w jakim scenariuszu użytkownik mógłby spróbować użyć w swoich danych wejściowych.

Scenariusz 2 spowodowałby problem tylko wtedy, gdy stał się globalnym w ramach funkcji. W przeciwnym razie jest poza zasięgiem i nieosiągalny.

+0

Czy jest to niebezpieczne ze względu na to, że jeśli niektóre dane wejściowe użytkownika będą zawierały MYSQL_PASSWORD, może to zostać przekazane przy użyciu rzeczywistego hasła? – alex

+0

To może się stać, jeśli zastosujesz drugą metodę, którą wymieniłeś. Zasadniczo określa ją jako zmienną globalną, widoczną w dowolnym zakresie. Możesz wybrać, w jaki sposób klasy lub funkcje mogą uzyskać dostęp do tablicy $ config, tak długo, dopóki nie będziesz jej widział w niewłaściwym zakresie, powinieneś być w porządku. –

+0

Edytowany post, aby podać przykład na dwa różne sposoby, w jaki można zdefiniować kod i jak użytkownik może uzyskać te informacje. –

1

Generalnie używam drugiej metody ... Podczas obsługi połączeń z bazami danych zazwyczaj otwieram połączenie na początku żądania, a następnie zamykam je na końcu. Mam funkcję, która ustanawia połączenie, a następnie usuwa nazwę użytkownika/hasło z tablicy globalnej (z funkcją unset()), Zapobiega to uzyskiwaniu dostępu do "wrażliwych" danych połączenia mysql przez inne części systemu.

0

Jestem również z opcją 2 dla większości wartości konfiguracyjnych. Jeśli masz były będzie zaimplementować klasę, to chciałbym powiązać konkretne wartości do klasy, która wpływa zamiast ogólnej konfiguracji klasy.

W twoim przykładzie twoja klasa byłaby dla połączeń z bazą danych, a instancja zapisałaby hasło, nazwę_bd, itd. Umożliwiłoby to prawidłowe enkapsulowanie danych, a także zapewniłoby łatwy sposób utworzenia wielu połączeń, gdyby było to kiedykolwiek potrzebne.

+0

Tak, to prawda, z wyjątkiem sytuacji, gdy chcesz edytować jeden plik, aby móc zmienić jakiekolwiek dane konfiguracyjne, wtedy stałe dołączone do klasy Db sprawią, że będzie trudniej niż jeden punkt dostępu (który jest tym, czego chcę). – alex

4

Powiedziałbym, że zależy to również od bazy użytkowników. Jeśli konfiguracje muszą być bardzo przyjazne dla użytkownika lub użytkownik musi mieć możliwość zmiany konfiguracji przez sieć itp.

Używam Zend Config Ini dla tego i innych ustawień są przechowywane w SQL DB.

+0

Nigdy wcześniej nie słyszałem o tej metodzie. Dobrze wiedzieć! –

Powiązane problemy