include не для слабонервных

[Prolix]

include не для слабонервных

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

Например, файл a1.php:

<?
if (!isset($a)) $a='beh';
if ($a=='action') include ('./a2.php');
elseif ($a=='demo') include ('./a2.php');
?>

Файл a2.php:

<?
$a.=' $$$';
echo $a;
?>

Естественно, вместо примитивных эхо идут обращения к базе данных и проч.

Стоит такая проблема: пользователи явно будут знать, что такой файл a2.php существует, и могут просто вызвать именно его. Таким образом, можно записывать всякий мусор в базу и т.д.

Как обойти эту проблему?

 

[iliyas]

Re: include не для слабонервных

Автор оригинала: Prolix
Задача такая: я хочу разбить проект по некоторым частям, скажем, какие-то операции вынести в отдельные файлы, чтобы потом эти файлы включать. Т.е. не включать огромный файл функций каждый раз и тем самым тормозить систему, а подключать только необходимые операции.

Например, файл a1.php:

<?
if (!isset($a)) $a='beh';
if ($a=='action') include ('./a2.php');
elseif ($a=='demo') include ('./a2.php');
?>

Файл a2.php:

<?
$a.=' $$$';
echo $a;
?>

Естественно, вместо примитивных эхо идут обращения к базе данных и проч.

Стоит такая проблема: пользователи явно будут знать, что такой файл a2.php существует, и могут просто вызвать именно его. Таким образом, можно записывать всякий мусор в базу и т.д.

Как обойти эту проблему?

<?
//$action - приходит из запроса
...
include ('$action/main.php');
?>
Каталог c именем $action делаешь недоступным по обращениям пользователей.
На месте '...' можешь вставить проверку прав или полную авторизацию. Напрямую обратится к $action/main.php будет невозможно.

 

[su1d]

if(!defined('SOME_CONSTANT')) die('Access denied');

SOME_CONSTANT opredeliaesh' v glavnom faile konfiguracii...

 

[Макс]

все подключаемые файлы записываешь в папку недоступную через http или просто в одну папку с .htaccess
deny from all

 

[Prolix]

про защиту директории я думал, но это слишком сложный вариант, к тому же, не всегда доступный. А вот su1d за простой и универсальный вариант спасибо!

 

[lunizz]

Положи в важные директории пустой index.html.
Самым важным файлам дай хитрые имена, вида 6fjksda87hsdf89.php (содержащие данные для коннекта к БД и тд).

 

[kvn]

делаем .htacces:

php_value include_path .:/home/www/data/test/php/lib:
php_value auto_prepend_file prepend.inc
DirectoryIndex index.php

<Files *.ihtml>
order allow,deny
deny from all
</Files>

<Files *.inc>
order allow,deny
deny from all
</Files>

include basename($action) . "scriprt.inc"

 

[lunizz]

Вот насчет файлов .inc - прописаны ли они у тебя как php-файлы в httpd.conf ? Дело в том, что если к такому файлу постучаться по http, и сервер поймет, что перед ним файл с незнакомым разрешением (Application Type), браузер предложит его сохранить на диск либо открыть из текущего места. А файл php просто попробует синтерпретироваться (и либо вывалит ошибку, либо чего-то произведет.)

 

[kvn]

Да, забыл, это тоже не помешает:
AddType application/x-httpd-php .php3, .php, .inc

Но это не есть проблема для ф-лов *.inc,
если ты к нему поломишься напрямую из броузера, то апаче дирректива:
<Files *.inc>
order allow,deny
deny from all
</Files>

Пошлет нафиг с You don't have permissions to view this file.

 

[lunizz]

Такой вопрос, это реально опробовано? Дело в том, что если ты хранишь в одной директории файлы inc, php (стандартные куски сайта), и картинки, gif/jpg/png, например, то картинки тоже станут недоступны для просмотра юзьверю. Я не помню, но почему-то пришлось отказаться мне от .htaccess для решения подобной проблемы. Просто давно было, не помню что глюкавило, но картинки - точно гнусавили.

 

[kvn]

Автор оригинала: lunizz
Такой вопрос, это реально опробовано? Дело в том, что если ты хранишь в одной директории файлы inc, php (стандартные куски сайта), и картинки, gif/jpg/png, например, то картинки тоже станут недоступны для просмотра юзьверю. Я не помню, но почему-то пришлось отказаться мне от .htaccess для решения подобной проблемы. Просто давно было, не помню что глюкавило, но картинки - точно гнусавили.

Да. Опробовано.
В диррективе же явно указано:
<Files *.inc>, т.е. под это условие попадают все файлы с расширением inc в текущей папке, и во всех вложенных.

 

[gRigoriy]

А зачем тебе хранить картинки в том же, защищенным .htaccess, каталоге ...

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

Да, и инклюдить надо только под-директории, каталога с инклюдами. Типа:

include("/some/dir/".$a.".php3");

 

[lunizz]

Автор оригинала: gRigoriy
А зачем тебе хранить картинки в том же, защищенным .htaccess, каталоге ...

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

Да, и инклюдить надо только под-директории, каталога с инклюдами. Типа:

include("/some/dir/".$a.".php3");

Оптимально.
Самый классный вариант. Чтоб до этого файла добраться, надо самому серваку голову свернуть /хотя зачем после этого нафих этот файлик? / Хотя честно, ни разу в жизни не использовал include. Сильно ssi отдает Все require, require_once делаю, нормально пашет.

 

[erudit]

Re: include не для слабонервных

Автор оригинала: Prolix
Задача такая: я хочу разбить проект по некоторым частям, скажем, какие-то операции вынести в отдельные файлы, чтобы потом эти файлы включать. Т.е. не включать огромный файл функций каждый раз и тем самым тормозить систему, а подключать только необходимые операции.

Например, файл a1.php:

<?
if (!isset($a)) $a='beh';
if ($a=='action') include ('./a2.php');
elseif ($a=='demo') include ('./a2.php');
?>

Файл a2.php:

<?
$a.=' $$$';
echo $a;
?>

Естественно, вместо примитивных эхо идут обращения к базе данных и проч.

Стоит такая проблема: пользователи явно будут знать, что такой файл a2.php существует, и могут просто вызвать именно его. Таким образом, можно записывать всякий мусор в базу и т.д.

Как обойти эту проблему?

товарисч! самый простой вариант проверять внутри этих инклюдов $PHP_SELF и если эта переменная содержит НЕ имя файла, в который он доложен инклюдится - exit и все.
давать навороченные имена файлам, чтобы юзер их не нашел - дилетантизм.

 

[erudit]

Автор оригинала: su1d

if(!defined('SOME_CONSTANT')) die('Access denied');

SOME_CONSTANT opredeliaesh' v glavnom faile konfiguracii...

гораздо проще и логичнее проверять не 'SOME_CONSTANT' а $PHP_SELF - если файл иклюдед куда надо будет имя этого этого "куда надо" а не самого иклюда.

 

[HEm]

Я использую объявление функций в выносимых файлах:

<?
function f1(...) {
...
}
?>

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

 

[Prolix]

Хохо! Как тут всех за сутки цепануло

В общем, проект, про который я написал - это Open Source. Т.е. все человеки имеют понятия, как какой файл называется и что он выполняет. Соответственно, они знают, где он лежит.

Этот вопрос снимает с повестки:
1) Защиту директории .htaccess-ом (доступно далеко не всем, геморно, долго; непонятно, зачем, если раньше этого не было)
2) Вообще любые действия, производимые с сервером.
3) "Хитрых" имен файлов не может существовать даже в теории.

erudit: насчет проще и логичнее я с вами не соглашусь. Во-первых, в этом случае в $PHP_SELF приписывается директория, в которой лежит скрипт (а он чаще всего лежит именно в поддиректории). Имени поддиректории я не знаю, следовательно, мне нужно отсекать все директории и получать имя файла (минус в производительности). Следовательно, мне имя этого файла надо точно где-то определить (что лишает меня возможности включить один сценарий в несколько файлов). В третьих, в свое время я намучался с глюками $PHP_SELF на разных серверах, и вообще отказался от ее использования.

В случае определения константы нам ничего проверять, отсекать не нужно. По сути, такую переменную нужно просто где-то объявить один раз, ее обозначение служит же лишь для того, чтобы подключаемый файл знал: раз переменная определена, значит, его действительно вызвали из другого скрипта. Фишка в том, что такую переменную нельзя передать через броузер, следовательно, все проблемы снимаются включением одной строчки в каждый подключаемый сценарий.

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

 

[erudit]

Автор оригинала: Prolix
.
.
.
erudit: насчет проще и логичнее я с вами не соглашусь. Во-первых, в этом случае в $PHP_SELF приписывается директория, в которой лежит скрипт (а он чаще всего лежит именно в поддиректории). Имени поддиректории я не знаю, следовательно, мне нужно отсекать все директории и получать имя файла (минус в производительности).

открываем мануал по пхп на Predefined variables и выбираем себе переменную по вкусу.
Например $_SERVER["SCRIPT_NAME"]
И не будет минуса в производительности при вводе новой переменной или константы (раз уж она тебя так заботит;-) )

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

открываем мануал и читаем про проблемы с $PHP_SELF когда пхп установлен как CGI
используем тот же _SERVER["SCRIPT_NAME"] чтобы не мучиться на разных хостингах =)

 

[Prolix]

erudit: еще раз повторюсь про то, что проект - Open Source, т.е. используют его неизвестно где, при каких установках и т.п. Чтобы избежать лишних проверок, нужен более-менее универсальный и простой вариант.

 

[HEm]

Автор оригинала: Prolix
самый главный минус - в функциях присутствует очень много глобальных переменных. Включение файла этот вопрос снимает...

В таких используй один глобальный массив для всех переменных