PHP включает расширения файлов?

Question

Для требуемых/включенных файлов в PHP лучше использовать .inc расширения vs .inc.php vs .php расширения?

Answer 1

Иногда люди используют расширение .inc, а затем выполняют некоторую конфигурацию сервера, чтобы поддерживать доступ к файлам .inc через веб-браузер. Это может быть быть хорошим, если все сделано правильно, знающим системным администратором, но есть лучший способ: любой файл, который не должен использоваться веб-пользователями, должен храниться вне вашего корня документа. Как только эти файлы отключены от сети, так сказать, вы можете использовать любое расширение, которое вы хотите. .php определенно является разумным выбором для подсветки синтаксиса, общего здравомыслия и т. Д.

Answer 2

Apache может иногда (из-за ошибок или серьезных сбоев) служить .php-файлами в виде текста (часто случается со мной на общем хостинге) .... Я думаю, вы можете использовать любое расширение, которое вы хотите, Храните файлы в общей папке.

Допустим, что ваш сайт находится в/главная/пользователь/public_html/

создать другую папку/главная/пользователя/lib_php/

есть файлы:

(1). ../lib_php/one.class.php с

class one { 
//... 
} 

(2) .../lib_php/two.function.php с

function two() { 
//... 
} 

и у вас есть главный index.php в/public_html

 
<?php 
include_once('../lib_php/one.class.php'); 
include_once('../lib_php/two.function.php');
 

$x=a; $b=two($x); $c=new one; //etc.. 

или

<?php 
require_once('/home/user/lib_php/the.file.php');

Таким образом, вы принимая все меры предосторожности, файлы недоступны напрямую, но могут использоваться вашими сценариями ...

Answer 3

Мое личное предпочтение заключается в том, что что-либо в корне документа является файлом .php, чтобы указать, что это прямое e исполняемый веб-сервером, и все, что является библиотекой, является .inc файлом, хранящимся в параллельном каталоге, чтобы указать, что он НЕ является исполняемым.

Моя стандартная конфигурация

/home/sites/example.com/html/ - все здесь есть «безопасный», чтобы выставить, если PHP не удается, и подает необработанный код

/home/sites/example.com/inc/ - библиотеки, конфигурационные файлы с паролями (например, класс подключения к базе данных с БД учетные данные) и т. д. Все, что не должно быть раскрыто, поскольку для этого нет оснований.

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

Конечно, если кровь Apache кашляет по всему полу, нет никакой причины, по которой защита обхода каталога не может потерпеть неудачу, и пусть кто-то сделает http://example.com/../inc/seekritpasswords.txt.

В какой-то момент вам просто нужно принять, что если что-то хранится где-нибудь на веб-сервере, есть вероятность, что сбой может разрешить доступ к необработанным данным и разоблачить все. Сколько времени и усилий вы потратите на защиту от этого зависит от вас.