Недостатки PHP в хранении соединения с MySQL PDO с помощью define

Question

Недостатки PHP в хранении соединения с MySQL PDO с помощью define

Каковы недостатки хранения подключения MySQL PDO с помощью define? Например,

define( 'DB_HOST', 'localhost' );
define( 'DB_USER', 'root' );
define( 'DB_PASS', 'xxx' );
define( 'DB_NAME', 'xxx' );
define( 'DSN', 'mysql:host='.DB_HOST.';dbname='.DB_NAME );

Я думал использовать const как этот пример но есть ограничение этого.

Например,

Я не могу сделать 'mysql:host='.DB_HOST.';dbname='.DB_NAME с const,
Я не могу сделать это ниже с const, а

(другая информация о конфигурации …)

define ( 'WEBSITE_DOCROOT', str_replace( '\\', '/', dirname( __FILE__ ) ).'/' );

define( 'SCHEME', isset( $_SERVER['HTTPS'] ) ? 'https://' : 'http://' );

define кажется, соответствует цели, но я не уверен, насколько это безопасно и что мне следует знать об использовании define для информации о настройках магазина? Любой совет?

Другой вариант — хранить их в классе,

$config = array(
'DB_USER' => 'root',
'DB_PW' => 'password'
);

Но там сказано с этим вариантом, the end user can screw the file and break the entire app(взято из Вот). Как пользователь может прикрутить файл?

2

const mysql pdo php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Что-нибудь вам define будет доступен для всех частей вашего PHP-кода, которые могут представлять угрозу безопасности. Если вы используете переменные, вы можете ограничить доступ к данным, потому что переменные имеют ограниченную область видимости.

Но, как говорится, с этой опцией, конечный пользователь может прикрутить файл и сломать все приложение (взято отсюда). Как пользователь может прикрутить файл?

В этом посте речь идет не о пользователе с точки зрения пользователя веб-сайта, а о пользователе самого кода (например, кто-то использует проект с открытым исходным кодом и редактирует конфигурацию).

2