Не работает include php

PHP: Почему нормально не работает include?

Когда функциия вызывается в том же файле, где расположена- работает нормально. Но стоит только вынести её в отдельный файл, а потом включить этот файл с include, require и т.п., функция сразу перестаёт работать.

10 ответов

Глобальных переменных не использую.

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

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

include ( «file1.php» ) ;
//include_once(«file1.php»);

Если функция определена в том же файле- всё работает.

Вставка return 0; не помогла.

то есть ты не понимаешь не работает инклюд или функция?
разрули постепенно
файл инклюдится, ато была бы ошибка
значин не пашет функция
напиши перед кодом функции просто

и посмотри вызывается ли она вообще. Если вызывается смотри код если нет смотри вызов 🙂

fnc_update(1,2,3,4);
если опять ОК не выскочит вырубай комп, отдыхай, а потом со свежими силами ищи по новой)))

Все manual’ы по include давно прочитала. В файле нет синтаксических ошибок.

Пробовала закоментировать содержимое функции- всё равно, когда запускается функция, перестаёт работать весь скрипт.

всё верно, LD 100.
Вот такой код:

я столкнулся с проблемой. В логах сервера увидел вот это:

в браузере вывод ошибок выключен.

необходимо было сначала определить переменную, что бы вывести массив.
Проблем то ли в настройках php то ли в версии php

Источник

Урок 8. Подключение файла в PHP. Include и require

Основы

Смысл подключения в php простым русским языком:

Файл 1.php
Верхнее меню

Файл 2.php
Нижнее меню

Файл example.php
Подкючаем Файл 1.php
Содержание страницы
Подкючаем Файл 2.php

В результате проработки файла example.php будет отображено
Верхнее меню
Содержание страницы
Нижнее меню
Соответственно, чтобы что-либо изменить в нижнем меню, нужно внести изменения только в файле 2.php

Путь к файлу

Код PHP

include и include_once

Рассмотрим работу include на примере двух файлов: index.php и text.php. Для простоты работы допустим, что они лежат в одной директории.

Код PHP (файл index.php)

Код PHP (файл text.php)

В результате работы файла index.php отобразится:

Обычный текст, содержащийся в основном файле
Текст, содержащийся в подключаемом файле
Правда удобно? Теперь, поменяв содержимое в файле text.php будет совершенно другой результат работы index.php!

Код PHP

require и require_once

Если не работает include или require

Чтобы понять причины того, почему не работает include, предлагаю проверить всё по шагам. Какими бы понятными и поверхностными не были указанные ниже пункты, проверьте всё с самого начала

1. Проверьте, работает ли Ваш сервер и php, работает ли вообще любой php код на сайте
2. Убедитесь, существует ли файл подключаемый файл
3. Проверьте, правильно ли введено название файла и расширение в подключении
4. Убедитесь, что подключаемый php-файл действительно находится по тому адресу, по которому указали
5. Попробуйте указать не относительный путь, а абсолютный (полный путь к файлу).

Пример Код PHP

6. Если у Вас не подключается файл и не отображается никакой ошибки, то в директории с файлом, который подключаете, создайте файл .htaccess со следующим содержимым

или в файле php, перед подключением, вставьте следующую строку

И та, и другая настройки будут принудительно отображать ошибки

Источник

Предупреждение безопасности

Удалённые файлы могут быть обработаны на удалённой стороне (в зависимости от расширения файла и того, что удалённый сервер выполняет скрипты PHP или нет), но это всё равно должно производить корректный скрипт PHP, потому что он будет затем обработан уже на локальном сервере. Если файл с удалённого сервера должен быть обработан и только отображён его результат, гораздо эффективно воспользоваться функцией readfile() В противном случае следует соблюдать особую осторожность, чтобы обезопасить удалённый скрипт для получения корректного и желаемого кода.

Смотрите также раздел Удалённые файлы, функции fopen() и file() для дополнительной информации.

Пример #4 Сравнение возвращаемого значения при include

// не сработает, интерпретируется как include((‘vars.php’) == TRUE), то есть include(‘1’)
if (include( ‘vars.php’ ) == TRUE ) <
echo ‘OK’ ;
>

// сработает
if ((include ‘vars.php’ ) == TRUE ) <
echo ‘OK’ ;
>
?>

Пример #5 Выражения include и return

?>

testreturns.php
= include ‘return.php’ ;

$bar = include ‘noreturn.php’ ;

Если во включаемом файле определены функции, они могут быть использованы в главном файле вне зависимости от того, были ли они объявлены до return или после. Если файл включается дважды, PHP выдаст фатальную ошибку, потому что функции уже были определены. Рекомендуется использовать include_once вместо того, чтобы проверять был ли файл уже включён.

Пример #6 Использование буферизации вывода для включения файла PHP в строку

Замечание: Поскольку это языковая конструкция, а не функция, она не может вызываться при помощи переменных функций.

User Contributed Notes 21 notes

If you want to have include files, but do not want them to be accessible directly from the client side, please, please, for the love of keyboard, do not do this:

// check if what is defined and die if not

?>

The reason you should not do this is because there is a better option available. Move the includeFile(s) out of the document root of your project. So if the document root of your project is at «/usr/share/nginx/html», keep the include files in «/usr/share/nginx/src».

# index.php (in document root (/usr/share/nginx/html))

?>

Since user can’t type ‘your.site/../src/includeFile.php’, your includeFile(s) would not be accessible to the user directly.

Before using php’s include, require, include_once or require_once statements, you should learn more about Local File Inclusion (also known as LFI) and Remote File Inclusion (also known as RFI).

As example #3 points out, it is possible to include a php file from a remote server.

The LFI and RFI vulnerabilities occur when you use an input variable in the include statement without proper input validation. Suppose you have an example.php with code:

However, it opens up an RFI vulnerability. To exploit it as an attacker, I would first setup an evil text file with php code on my evil.com domain.

The example.php would download my evil.txt and process the operating system command that I passed in as the command variable. In this case, it is whoami. I ended the path variable with a %00, which is the null character. The original include statement in the example.php would ignore the rest of the line. It should tell me who the web server is running as.

Please use proper input validation if you use variables in an include statement.

dir1/test contains the following text :
This is test in dir1
dir2/test contains the following text:
This is test in dir2
dir1_test contains the following text:
This is dir1_test
dir2_test contains the following text:
This is dir2_test

As a rule of thumb, never include files using relative paths. To do this efficiently, you can define constants as follows:

and so on. This way, the files in your framework will only have to issue statements such as this:

If you’re running scripts from below your main web directory, put a prepend.php file in each subdirectory:

I would like to point out the difference in behavior in IIS/Windows and Apache/Unix (not sure about any others, but I would think that any server under Windows will be have the same as IIS/Windows and any server under Unix will behave the same as Apache/Unix) when it comes to path specified for included files.

Consider the following:
include ‘/Path/To/File.php’ ;
?>

In IIS/Windows, the file is looked for at the root of the virtual host (we’ll say C:\Server\Sites\MySite) since the path began with a forward slash. This behavior works in HTML under all platforms because browsers interpret the / as the root of the server.

However, Unix file/folder structuring is a little different. The / represents the root of the hard drive or current hard drive partition. In other words, it would basically be looking for root:/Path/To/File.php instead of serverRoot:/Path/To/File.php (which we’ll say is /usr/var/www/htdocs). Thusly, an error/warning would be thrown because the path doesn’t exist in the root path.

I just thought I’d mention that. It will definitely save some trouble for those users who work under Windows and transport their applications to an Unix-based server.

A work around would be something like:
= null ;

if ( defined ( ‘__DIR__’ )) <
$currentDirectory = __DIR__ ;
>
else <
$currentDirectory = dirname ( __FILE__ );
>

It’s worth noting that PHP provides an OS-context aware constant called DIRECTORY_SEPARATOR. If you use that instead of slashes in your directory paths your scripts will be correct whether you use *NIX or (shudder) Windows. (In a semi-related way, there is a smart end-of-line character, PHP_EOL)

Sometimes it will be usefull to include a string as a filename

Ideally includes should be kept outside of the web root. That’s not often possible though especially when distributing packaged applications where you don’t know the server environment your application will be running in. In those cases I use the following as the first line.

Be very careful with including files based on user inputed data. For instance, consider this code sample:

file_exists() will return true, your passwd file will be included and since it’s not php code it will be output directly to the browser.

Of course the same vulnerability exists if you are reading a file to display, as in a templating engine.

You absolutely have to sanitize any input string that will be used to access the filesystem, you can’t count on an absolute path or appended file extension to secure it. Better yet, know exactly what options you can accept and accept only those options.

If you are including a file from your own site, do not use a URL however easy or tempting that may be. If all of your PHP processes are tied up with the pages making the request, there are no processes available to serve the include. The original requests will sit there tying up all your resources and eventually time out.

Use file references wherever possible. This caused us a considerable amount of grief (Zend/IIS) before I tracked the problem down.

If you have a problem with «Permission denied» errors (or other permissions problems) when including files, check:

1) That the file you are trying to include has the appropriate «r» (read) permission set, and
2) That all the directories that are ancestors of the included file, but not of the script including the file, have the appropriate «x» (execute/search) permission set.

I would like to emphasize the danger of remote includes. For example:
Suppose, we have a server A with Linux and PHP 4.3.0 or greater installed which has the file index.php with the following code:

Then, we hava a server B, also Linux with PHP installed, that has the file list.php with the following code:

But here’s the trick: if Server B doesn’t have PHP installed, it returns the file list.php to Server A, and Server A executes that file. Now we have a file listing of Server A!
I tried this on three different servers, and it allways worked.
This is only an example, but there have been hacks uploading files to servers etc.

So, allways be extremely carefull with remote includes.

Just about any file type can be ‘included’ or ‘required’. By sending appropriate headers, like in the below example, the client would normally see the output in their browser as an image or other intended mime type.

You can also embed text in the output, like in the example below. But an image is still an image to the client’s machine. The client must open the downloaded file as plain/text to see what you embedded.

( ‘Content-type: image/jpeg’ );
header ( ‘Content-Disposition: inline;’ );

include ‘/some_image.jpg’ ;
echo ‘This file was provided by example@user.com.’ ;

‘Including’ any file made this way will execute those scripts. NEVER ‘include’ anything that you found on the web or that users upload or can alter in any way. Instead, use something a little safer to display the found file, like «echo file_get_contents(‘/some_image.jpg’);»

To Windows coders, if you are upgrading from 5.3 to 5.4 or even 5.5; if you have have coded a path in your require or include you will have to be careful. Your code might not be backward compatible. To be more specific; the code escape for ESC, which is «\e» was introduced in php 5.4.4 + but if you use 5.4.3 you should be fine. For instance:

Test script:
————-
require( «C:\element\scripts\include.php» );
?>

In php 5.3.* to php 5.4.3
—————————-
If you use require(«C:\element\scripts\include.php») it will work fine.

If php 5.4.4 + It will break.
——————————
Warning: require(C:←lement\scripts\include.php): failed to open stream: In
valid argument in C:\element\scripts\include.php on line 20

Fatal error: require(): Failed opening required ‘C:←lement\scripts\include.php

I hope this makes sense and I hope it will someone sometime down the road.
cheers,

// used like
include_all_once ( ‘dir/*.php’ );

?>
A fairly obvious solution. It doesn’t deal with relative file paths though; you still have to do that yourself.

Notice that using @include (instead of include without @) will set the local value of error_reporting to 0 inside the included script.

echo «Own value before: » ;
echo ini_get ( ‘error_reporting’ );
echo «\r\n» ;

echo «include foo.php: » ;
include( ‘foo.php’ );

echo «@include foo.php: » ;
@include( ‘foo.php’ );

While you can return a value from an included file, and receive the value as you would expect, you do not seem to be able to return a reference in any way (except in array, references are always preserved in arrays).

i.e the reference passed to x() is broken on it’s way out of the include()

The only solutions are to set a variable with the reference which the including code can then return itself, or return an array with the reference inside.

Источник

Проблема включения файла include в php

include ‘../db.php’; работает и файл считывается, но

Warning: include(../db.php): failed to open stream: No such file or directory

3 ответа 3

Ответ выше неправильный. Относительный путь нельзя использовать никогда. При любых файловых операциях всегда надо использовать абсолютный путь.

Если db.php лежит в корне сайта, то писать надо так

и это будет работать в любых папках.

«../» означает «на один уровень выше». А «./» означает «здесь».
Чтобы понять где это, надо разобраться что считается «текущей директорией».

При обращении к php-скрипту через веб-сервер, текущая директория та, где находится «точка входа», т.е. вызываемый скрипт.

А при вызове консольного скрипта, текущая директория это та, в которой находится пользователь или системный процесс, вызывающий этот скрипт и не зависит от расположения вызываемого php-скрипта.

Если скрипт A инклудит срипт Б, а тот в свою очередь инклудит В и т.д., то в каких бы папках не находились Б и В, текущая папка уже не изменяется. Отсчет идет от одной и той же папки!

Совет Ипатьева годится только для веб-скриптов и к тому же не позволит переместить приложение в какую-нибудь под-папку без правки исходников.

Источник

PHP include уязвимость: от теории к практике

В этой статье я расскажу вам об одной из самых распространённых уязвимостей, встречающихся в php-сценариях — include «баге». Вы узнаете как принцип действия, так и некоторые способы устранения данной уязвимости.

Внимание. Вся информация представленная в данной статье служит чисто в ознакомительных целях! Автор не несёт никакой ответственности за её злонамеренное применение!

Уязвимость php — include одна из самых известных, но между тем и самых распространённых «дыр» встречающихся сегодня в php сценариях. Она возникает, когда по невнимательности, незнанию, либо по какой-то другой ведомой только ему одному причине, программист позволяет использовать данные, переданные сценарию в виде параметров, без дополнительной проверки (такие данные ещё называют «мечеными») в качестве параметра функцией include. Для того, чтобы лучше разобраться в принципе действия данной уязвимости, необходимо иметь некоторое представление о вышеназванной функции.

php функция include, а также include_once

Данная функция используется для подключения к запущенному php сценарию дополнительных программных модулей. Причём, в отличие от похожей по свойствам require, функция include исполняет эти модули непосредственно в своём процессе. А следовательно, прикрепляемые таким образом модули будут исполняться не как отдельные сценарии, а как части подключившего их к себе сценария. Точнее, include будет исполнять только ту часть файла, которая заключена между спец. тэгами:

Всё остальное php просто выдаёт в виде текста. Т.е. если подключить текстовый файл (например: /etc/passwd 🙂 ) не содержащий указанных тэгов, всё содержимое этого файла будет выдано интерпретатором.

Как вы наверное заметили, функция include имеет всего 1 параметр ($file), который указывает путь и имя файла подключаемого модуля. Стоит отметить также, что в юниксоподобных системах (в зависимости от настроек php) в качестве параметра можно передавать не только путь и имя файла, но и url (Интернет адрес) файла(. ).

Предположим, на некотором ВЕБ-сервере установлен следующий php сценарий (его url http://www.superpupersite.com/index.php):

А также множество различных подключаемых сценариев-модулей для него:

Автор этого сценария предполагал, что все посетители сайта будут мирно переходить от одной страницы к другой нажимая кнопочки, ссылочки и прочие объекты управления. А сценарий, в зависимости от переданного параметра file, будет присоединять один или другой модуль, таким образом генерируя различные html страницы (чаще всего include используют именно таким образом).

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

Сделал запрос вида: http://www.superpupersite.com/index.php?file=/etc/passwd
На выходе получил содержимое файла passwd сервера
П.С: Если на сервере в опциях php включен режим отладки, выявить подобную уязвимость не составляет особого труда по характерным сообщениям о ошибках (Вроде: «failed opening ‘filename’ for inclusion…»! Но в данном случае режим отладки был отключён (не всё коту масленица).

«Здорово! Вполне возможно что моё предположение по поводу include верно!»-подумал Вася. А также Вася заметил, что сервер работает под управлением юниксподобной операционной системы (там присутствует файл /etc/passwd). Из этого всего он сделал вывод, что возможно удастся внедрить свой php модуль, чтобы последний выполнялся на стороне сервера. Теперь, для осуществления своих зловещих планов, В.Пупкину необходим доступ позволяющий добавлять и редактировать файлы на каком-нибудь ВЕБ-сервере. К счастью, на сегодняшний день получить медленный, бесплатный хостинг не составляет особых проблем и у нашего героя уже был припасён на такие неожиданные 🙂 случаи жизни свой сайт http://pupkin.halava123.ru. Куда он предусмотрительно закачал сценарий следующего содержания:

Незатейливый, надо сказать, скрипт, выводящий в окно браузера список файлов и каталогов в текущей директории (но для проверки наличия уязвимости его хватит 🙂 ). Сценарий был размещён по адресу:

Вася выполнил следующий запрос:

И у него получилось! Как и задумывалось, в окне браузера он увидел список файлов и каталогов. Далее по нарастающей, «дыра» была обнаружена, и в ход пошли не менее интересные сценарии, подробное описание которых заняло бы немало места и по этим соображениям не публикуется здесь 🙂 В общем, долго ли, коротко ли, но закончилось всё дефейсом (дефейс — подмена начальной страницы на свою). Вот такая грустная история!

Борьба с вредителем

Более сложный с точки зрения реализации метод борьбы с вредителями 🙂 — это создание отдельного файла-списка модулей, которые возможно запустить. И в зависимости, находится ли тот или иной модуль в списке, выполнять либо выдавать соответствующую ошибку (или запускать модуль по умолчанию или если Вы, хотите напугать «экспериментатора» выдать сообщение о том, что его адрес зафиксирован и чтоб он сушил сухари…).
Пример:

Третий метод является промежуточным- что-то среднее между 1-ым и 2-ым. Вам просто надо заменить все служебные символы («..»,»/»,»») например, на прочерки. Правда, модули (там должны располагаться только выполняемые модули и ничего кроме них. ) в этом случае должны располагаться в одном каталоге, но их названия могут быть нормальными словами (например “news”, ”guestbook” и т.д.).
Заключение

Вот в общем-то и всё, что я хотел рассказать вам в этот раз. Вывод из этого всего может быть такой: прежде чем используете данные полученные от пользователя в ваших web сценариях подумайте, а не надо ли их предварительно проверить и надлежащим образом обработать. Это касается не только полей данных формы передаваемых браузером (методы get и post), но и cookie (злоумышленник может добраться и до них).

Источник