Насколько я понимаю, ваша задача не требует очереди с приоритетами, так как ваши задачи звучат как «Сделайте много вставок, после этого отсортируйте все». Это как стрельба по птицам из лазера, а не подходящий инструмент. Для этого используйте стандартные методы сортировки.
Вам понадобится Приоритетная очередь, если ваша задача состоит в том, чтобы имитировать последовательность операций, где каждая операция может быть либо «Добавить элемент в набор», либо «Удалить наименьший / наибольший элемент из набора». Это может быть использовано, например, при поиске кратчайшего пути на графе. Здесь вы не можете просто использовать стандартные методы сортировки.
Вы также можете рассмотреть возможность переноса комбинации имени пользователя и пароля в отдельный файл конфигурации, который находится вне корневого веб-сайта. Убедитесь, что это место недоступно напрямую со стороны веб-сервера.
Таким образом, если по какой-то причине веб-сервер решит больше не выполнять файлы PHP, вы не потеряете информацию об учетной записи для сервера базы данных.
В качестве дополнительного бонуса, если вы используете что-либо, что делает копию файла .php (редакторы, SVN или что-то еще) в корневом веб-каталоге, вы не рискуете обойти выполнение .php.
Это очень стандартная процедура для веб-приложений, которые взаимодействуют с базой данных.
Я рекомендую снять разрешения на чтение с файла для пользователей, кроме веб-сервера и вас самих - если у вас есть другие пользователи на вашем ящике, который может шпионить за файлом, они смогут получить доступ к вашему серверу mysql.
Кроме того, вы должны настроить разрешение исполняемого файла в верхнем каталоге, так как это предотвратит доступ неавторизованных пользователей даже к нему.
Усильте разрешенный хост вашего пользователя mysql, чтобы к нему могли подключаться только те устройства, которые вам нужны.
Конечно, если ваш компьютер скомпрометирован и злоумышленник получит root-доступ, мало что защитит вас.
Вы можете добавить некоторый дополнительный уровень безопасности, поместив все ваши php-файлы (кроме index.php, конечно) в отдельный каталог и защитив их файлом .htaccess. Это касается случаев, когда парсер php не вызывается, а apache возвращает файлы в виде открытого текста. Еще одна вещь, которая может быть полезна: Php defined ('some_id_here') или die (); ?>
. Вы можете поместить его в начало каждого файла php, кроме index.php (где вы определяете some_id_here), чтобы не было прямого доступа к вашим файлам базы данных.
Отсутствие основной части кода в корневом веб-каталоге, где это возможно, хотя и маловероятно, - это лишь первая линия защиты, которую можно предпринять.
Ваша база данных также должна быть защищена, даже если пользователь базы данных и пароль были опубликованы - с помощью простого средства, разрешив лишь небольшому количеству исходных машин подключаться к базе данных в любом случае.
Глубокая защита
<?php // simplest /index.php, as the only .PHP file in the public-accessible webroot
require '../bootstrap.php';
Я не знаю, как вы подключаетесь к вашему MySQL база данных, но если вы используете PDO, есть вероятность, что конструктор PDO выдаст исключение. Если вы не поймаете это исключение, Zend Engine по умолчанию покажет обратную трассировку и покажет детали вашего подключения!
Это нормально - хранить кредиты подключения внутри файла / переменной php или, в этом случае вы используете PDO, в DSN (имя источника данных). Я бы даже посоветовал вам поместить его в файл php, потому что он будет анализироваться, а не отправляться в Интернет в открытом виде ...
Один из шагов к большей безопасности - поместить данные для входа за пределы www-root или защитить его с файлом .htaccess (это сделало бы невозможным доступ к файлу через веб-сервер).
Однако на моем сервере невозможно подключиться , но не с localhost. Так что меня не волнует, прочитает ли кто-нибудь мои данные для входа (конечно, это не так).
Любой, кто может войти в систему с правами суперпользователя на этом веб-сервере (или, возможно, с более низкими), сможет увидеть ваш пароль, но тогда практически невозможно защитить от суперпользователя (где бы вы ни хранили пароль, они могли взломать и найти его). Помимо этого риска, вы должны быть в безопасности.
Изменить: резервные копии сервера также могут быть использованы (если они не зашифрованы, или кем-то, кто может их расшифровать) для восстановления вашего пароля, если он неясен в вашем .php скрипте. Эта возможная атака, возможно, может быть уменьшена (с большим неудобством / стоимостью), если сохранить пароль в другом, безопасном месте, и отправлять его (безопасно) только при очень ограничительных обстоятельствах. Вы боитесь такой атаки?