Стоит ли менять мой код на «более портативный» и способен справиться с ужасом магических кавычек, или я должен просто убедиться, что он всегда отключен через файл .htaccess?
if (get_magic_quotes_gpc()) { $var = stripslashes($_POST['var']); } else { $var = $_POST['var']; } Против
php_flag magic_quotes_gpc off
Не учитывайте обе ситуации. Два пути кода – в два раза больше головных болей, плюс есть хороший шанс, что вы соскользните и забудете обойти обе ситуации где-нибудь.
Раньше я проверял, включены или выключены магические кавычки, и если они были включены, отмените их магию (как предложили другие в потоке). Проблема заключается в том, что вы меняете настроенную среду (независимо от того, насколько глупый), что может ожидать другой программист.
В эти дни я пишу код, как будто волшебные кавычки отключены, и в моем основном файле include / bootstrap / always-running я проверяю, включены или отключены магические кавычки. Если они работают, я бросаю исключение, которое объясняет, почему это плохо , и дайте инструкции о том, как их можно отключить.
Этот подход позволяет вам кодировать одно поведение, побуждает других людей, используя ваш код, правильно настроить свои серверы (магические кавычки уходят на PHP 6), и если кому-то действительно нужны магические кавычки, они могут справиться с вашим исключением и занять их жизнь в свои руки.
Я бы проверил настройку с помощью get_magic_quotes_gpc() и сделал большой шумный выход с ошибкой. При ошибке сообщите администратору о правильной настройке.
Я бы удостоверился, что это возможно, если это возможно (требуется доступ к конфигурации .htaccess или apache). Лучше избегать этого вообще, чем снимать его поведение, которое требует больше ресурсов и подвержено ошибкам.
Если отключить его, это не вариант, ваш примерный код может быть полезен для входных суперглобалов ($ _GET, $ _ POST, …), но не применяйте его к данным, поступающим из источников, отличных от этих суперклассов. Такое злоупотребление довольно распространено .
Просто убедитесь, что при отключении magic_quotes_gpc () вы получите надлежащий механизм экранирования, чтобы защитить вас от SQL-запросов (например, mysql_real_escape_string () или подготовленных отчетов PDO). Вы можете больше узнать о предотвращении внедрения SQL – здесь .
На большей стороне примечания php 6 больше не будет их поддерживать. Поэтому написание кода для них может быть полезным в будущем.