Забороніть прямий доступ до файлу, що включає php


166

У мене є файл PHP, який я буду використовувати виключно як включення. Тому я хотів би викинути помилку, а не виконувати її, коли до неї звертаються безпосередньо, ввівши URL, а не включаючи.

В основному мені потрібно зробити перевірку наступним чином у файлі php:

if ( $REQUEST_URL == $URL_OF_CURRENT_PAGE ) die ("Direct access not premitted");

Чи є простий спосіб це зробити?


10
замість die () слід протестувати заголовок '("Файл HTTP / 1.1 404 не знайдено", 404); вихід;'. Це (принаймні, на apache) змусить сервер повернути нормальну сторінку 404.
gnud

Ось два простих способи, які я пояснив, щоб відключити прямий доступ до файлів, що включають PHP - codepeedy.com/disable-direct-access-to-the-php-include-file
Faruque Ahamed Mollick

Відповіді:


173

Найпростіший спосіб для загальної ситуації "PHP-додаток, що працює на сервері Apache, який ви можете або не можете повністю контролювати", - помістити свої включення в каталог і заборонити доступ до цього каталогу у вашому файлі .htaccess. Щоб врятувати людям проблеми Google, якщо ви використовуєте Apache, помістіть це у файл під назвою ".htaccess" у каталозі, до якого ви не хочете бути доступним:

Deny from all

Якщо ви справді маєте повний контроль над сервером (частіше в наші дні навіть для невеликих додатків, ніж коли я вперше написав цю відповідь), найкращим підходом є приклеювання файлів, які ви хочете захистити за межами каталогу, від якого обслуговується ваш веб-сервер. . Тож якщо у вашій програмі є /srv/YourApp/, встановіть сервер для обслуговування файлів /srv/YourApp/app/і додайте включені /srv/YourApp/includes, так що буквально немає жодної URL-адреси, яка може отримати доступ до них.


1
Дякую, оскільки я маю повний контроль над сервером, на якому я запускаю цю програму, це відповідь, з якою я пішов.
Alterlife

24
якщо ви повністю контролюєте сервер, краще, якщо ви введете конфігурацію в директиву каталогу у віртуальний конфігураційний файл хоста. Apache читає його лише один раз при запуску, .htaccess читається при кожному доступі та сповільнює роботу сервера
Eineki

22
Було б непогано мати приклад .htaccess-файлу як частину цієї відповіді.
Грем Леа

7
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
Дракорат

11
@James: Крім того, не всі вважають, що переповнення стека має бути сайтом "надіслати код". Якщо вона відповідає на питання чітко, то це хороша відповідь. Наведення прикладу, коли нічого не потрібне, лише заохочує кодування копіювання та вставки.
Чак

188

Додайте це на сторінку, яку ви хочете лише включити

<?php
if(!defined('MyConst')) {
   die('Direct access not permitted');
}
?>

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

<?php
define('MyConst', TRUE);
?>

3
Мені дійсно потрібно навчитися вводити швидше. Я б сказав так, як його більш безпечний, ніж метод, який використовує змінну для перевірки. Оскільки з деякими налаштуваннями PHP можливо змінити змінну.
Марк Девідсон

3
Ось як це справляється з декількома програмами "mainstream". Я знаю, що Joomla робить це так, і я думаю, що Wiki, Wordpress та інші.
UnkwnTech

1
Можливо, повідомлення є надто корисним для хакера (жоден реальний користувач не знайде цих сторінок), ви можете просто надіслати заголовок переспрямування та зупинити обробку php.
Банді

7
Просто надішліть заголовок 404 та вийдіть - сторінка помилок буде виглядати ідентично звичайній 404 сторінки (принаймні на Apache).
gnud

4
@ Smile.Hunter: мова йде про блокування доступу до перегляду файлів скриптів включення / бібліотеки безпосередньо, відповідь працює. Якщо вони створили somefile.phpна вашому сервері і додали на нього визначення, це все ще не дозволяє їм безпосередньо отримувати доступ до файлу включення. Це дозволить їм "включити" ваші бібліотечні файли, але якщо вони дістаються досить далеко, щоб створювати файли на вашому сервері та знаючи ваші сценарії визначення / включення, у вас є інші проблеми, які, ймовірно, заперечують написання власного файлу з вашим визначенням в першу чергу .
Джеймс

114

У мене є файл, який мені потрібно діяти інакше, коли він включений проти, коли до нього звертаються безпосередньо (головним чином print()проти vs return()) Ось кілька модифікованих кодів:

if(count(get_included_files()) ==1) exit("Direct access not permitted.");

Файл, до якого отримують доступ, - це завжди включений файл, звідси == 1.  


12
Це насправді пекла ідея, перевірка включеного числа файлів. Цікаво, що краще: використання визначень чи використання цього методу? Це здається більш самостійним.
Akoi Meexx

Вперше я бачив, щоб хтось придумував це. Я не знаю, навіщо, тому що, здається, є самодостатньою, як це можливо, і це безпосередньо вимірювання того, що ви насправді хочете знати (якщо він включений чи ні), а не вимірювання чогось, що вважається асоційованим (наприклад, певна константа чи певне місцезнаходження, заборонене .htaccess). Гарний.
Jimbo Jonny

Це дуже здорово, оскільки використання .htaccess для блокування всіх .php-файлів може бути неможливим постійно, оскільки в одному каталозі можуть бути деякі файли, які потрібно викликати безпосередньо або навіть javascripts. Дякую за цю чудову ідею!
Ануй

3
Це працює лише в PHP5 і вище. Перед PHP5 ви хочете порівняти ще раз 0 замість 1.
jmucchiello

Це дійсно розумне рішення і дозволяє контролювати прямий доступ, а не просто блокувати його - ось що мені подобається. Я зазвичай включаю тестування одиниць у самі файли, і таким чином я можу зафіксувати тестування одиниць у цьому операторі if. Цікаво, наскільки це ефективно ..
whiteatom

34

Найкращий спосіб запобігти прямому доступу до файлів - розмістити їх поза корінком документа веб-сервера (як правило, на один рівень вище). Ви все ще можете їх включити, але немає можливості, щоб хтось звернувся до них через http-запит.

Зазвичай я проходжу весь шлях і розміщую всі мої файли PHP поза корінцем документа, окрім завантажувального файлу - самотнього index.php в корені документа, який починає маршрутизацію всього веб-сайту / програми.


3
Це чудове рішення, якщо ви можете це зробити. Мені нещодавно довелося почати працювати з спільними веб-хостингами і виявив одне з багатьох роздратовань, що все повинно бути всередині докрозу.
Beau Simensen

3
У кожного постачальника хостингу, з яким я працював, я завжди мав доступ до (рівно) одного рівня над коренем документа.
Еран Гальперін

3
На деяких хостах (включаючи мій поточний) ви можете вказати свій домен на потрібну папку.
Діна

1
Це також хороша альтернатива .. використовуючи preg_match -> if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Попередження безпеки приладу - Прямий доступ заборонено! Ваш IP-запис зареєстровано! <h3> '); // Зупинити подальше виконання}
MarcoZen

Цей URL devzone.zend.com/node/view/id/70 є 404. Відповідь повинна містити код, який спочатку використовувався з цього неіснуючого URL-адреси.
Funk Forty Niner

31

1: Перевірка кількості включених файлів

if( count(get_included_files()) == ((version_compare(PHP_VERSION, '5.0.0', '>='))?1:0) )
{
    exit('Restricted Access');
}

Логіка: PHP виходить, якщо мінімальний кількість включень не дотримана. Зауважте, що до початку PHP5 базова сторінка не вважається включеною.


2: Визначення та перевірка глобальної константи

// In the base page (directly accessed):
define('_DEFVAR', 1);

// In the include files (where direct access isn't permitted):
defined('_DEFVAR') or exit('Restricted Access');

Логіка: Якщо константа не визначена, виконання не починається з базової сторінки, і PHP припинить виконання.

Зауважте, що заради переносимості через оновлення та майбутні зміни, внесення цього методу аутентифікації модульним значно зменшить накладні витрати кодування, оскільки зміни не потрібно сильно кодувати для кожного окремого файлу.

// Put the code in a separate file instead, say 'checkdefined.php':
defined('_DEFVAR') or exit('Restricted Access');

// Replace the same code in the include files with:
require_once('checkdefined.php');

Таким чином можна додати додатковий код checkdefined.php для ведення журналу та аналітичних цілей, а також для створення відповідних відповідей.

Кредит, де належить кредит: Блискуча ідея портативності виникла з цієї відповіді .


3: Віддалена авторизація адреси

// Call the include from the base page(directly accessed):
$includeData = file_get_contents("http://127.0.0.1/component.php?auth=token");

// In the include files (where direct access isn't permitted):
$src = $_SERVER['REMOTE_ADDR']; // Get the source address
$auth = authoriseIP($src); // Authorisation algorithm
if( !$auth ) exit('Restricted Access');

Недолік цього методу - це ізольоване виконання, за винятком випадків, коли маркер сеансу надається із внутрішнім запитом. Перевірте за допомогою зворотної адреси циклу у випадку конфігурації одного сервера або білого списку адреси для багатосерверної або збалансованої завантаженням серверної інфраструктури.


4: Авторизація маркера

Як і в попередньому методі, можна використовувати GET або POST для передачі маркера авторизації у файл включення:

if($key!="serv97602"){header("Location: ".$dart);exit();}

Дуже безладний метод, але також, мабуть, найбільш безпечний і універсальний водночас, коли використовується правильним чином.


5: Конфігурація веб-сервера

Більшість серверів дозволяють призначити дозволи для окремих файлів чи каталогів. Ви можете розмістити всі ваші включення в таких обмежених каталогах і налаштувати сервер, щоб заборонити їх.

Наприклад, в APACHE, конфігурація зберігається у .htaccessфайлі. Підручник тут .

Зверніть увагу , однак , що конфігурації сервера специфічні не рекомендується мною , тому що вони погано для портативності між різними веб-серверами. У таких випадках, як Системи управління контентом, коли алгоритм заперечення складний або список відхилених каталогів досить великий, це може зробити лише сеанси конфігурації досить жахливими. Зрештою, найкраще це обробити в коді.


6: Розміщення включає в захищену директорію ВНУТРІЙ корінь сайту

Найменше переважний через обмеження доступу в середовищі сервера, але досить потужний метод, якщо у вас є доступ до файлової системи.

//Your secure dir path based on server file-system
$secure_dir=dirname($_SERVER['DOCUMENT_ROOT']).DIRECTORY_SEPARATOR."secure".DIRECTORY_SEPARATOR;
include($secure_dir."securepage.php");

Логіка:

  • Користувач не може вимагати жодного файлу поза htdocsпапкою, оскільки посилання виходять за межі адресної системи веб-сайту.
  • PHP-сервер отримує доступ до файлової системи в оригінальному режимі, а отже, може отримати доступ до файлів на комп'ютері так, як може звичайна програма з необхідними привілеями.
  • Розмістивши файли включення в цьому каталозі, ви можете переконатися, що сервер php отримує доступ до них, тоді як гарячі посилання користувачеві відмовляються.
  • Навіть якщо конфігурація доступу до файлової системи веб-сервера не була виконана належним чином, цей спосіб запобігає випадковому опублікуванню цих файлів.

Вибачте, будь ласка, мої неортодоксальні умови кодування. Будь-який відгук вдячний.


мені подобається число 2
Байм Неправильно

26

Альтернативою (або доповненням) до рішення Чака було б забороняти доступ до файлів, що відповідають певній схемі, додаючи щось подібне у свій .htaccess файл

<FilesMatch "\.(inc)$">
    Order deny,allow
    Deny from all
</FilesMatch>

Я вважаю, що краще використовувати .inc.php Я вважаю, і це звичайна практика
Лис

14

Насправді моя порада - виконувати всі ці найкращі практики.

  • Помістіть документи за межами веб-кореневища АБО у каталог, яким веб-сервер заборонений у доступі І
  • Використовуйте визначення у своїх видимих ​​документах, на які приховані документи перевіряють:
      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

Таким чином, якщо файли якимось чином не поміщаються (помилкова операція ftp), вони все одно захищені.


8

У мене була ця проблема один раз, і вона вирішила:

if (strpos($_SERVER['REQUEST_URI'], basename(__FILE__)) !== false) ...

але ідеальним рішенням є розміщення файлу за межами кореня документа веб-сервера, про що йдеться в іншому оглядачі.


7

Вам краще побудувати додаток з однією точкою входу, тобто всі файли повинні бути отримані з index.php

Розмістіть це в index.php

define(A,true);

Ця перевірка повинна запускатися у кожному пов'язаному файлі (через вимагати або включати)

defined('A') or die(header('HTTP/1.0 403 Forbidden'));

7

Я хотів обмежити доступ до файлу PHP безпосередньо, але також міг викликати його через jQuery $.ajax (XMLHttpRequest). Ось що для мене спрацювало.

if (empty($_SERVER["HTTP_X_REQUESTED_WITH"]) && $_SERVER["HTTP_X_REQUESTED_WITH"] != "XMLHttpRequest") {
    if (realpath($_SERVER["SCRIPT_FILENAME"]) == __FILE__) { // direct access denied
        header("Location: /403");
        exit;
    }
}

3

Найпростіший спосіб - встановити певну змінну у файлі, до якої належать дзвінки, наприклад

$including = true;

Потім у файлі, що входить, перевірте змінну

if (!$including) exit("direct access not permitted");

2
Це небезпечно, якщо увімкнено register_globals.
jmucchiello

25
PHP небезпечний, якщо увімкнено register_globals.
Девід Прешерний

3

Крім способу .htaccess, я бачив корисну схему в різних рамах, наприклад, в рубіні на рейках. Вони мають окремий паб / каталог у кореневому каталозі додатків, а бібліотечні каталоги перебувають у каталогах на тому ж рівні, що і pub /. Щось подібне (не ідеально, але ви розумієте):

app/
 |
 +--pub/
 |
 +--lib/
 |
 +--conf/
 |
 +--models/
 |
 +--views/
 |
 +--controllers/

Ви налаштували веб-сервер для використання pub / як кореня документа. Це забезпечує кращий захист ваших сценаріїв: хоча вони можуть вийти з кореня документа для завантаження необхідних компонентів, доступ до компонентів з Інтернету неможливий. Ще одна перевага крім безпеки - це те, що все знаходиться в одному місці.

Це налаштування краще, ніж просто створення перевірок у кожному включеному файлі, оскільки повідомлення "доступ не дозволений" є підказкою для зловмисників, і це краще, ніж конфігурація .htaccess, оскільки це не на основі білого списку: якщо ви накрутите розширення файлу його не буде видно в каталогах lib /, conf / etc.


Через довгий час я просто хочу прокоментувати, що модель, яку ви описали вище, називається моделлю MVC (Model - View - Controller). Якщо ви хочете, перевірте google та додайте додаткову інформацію до своєї відповіді. Також MVC підтримує не тільки додатки Ruby on Rails та ASP.NET, але і PHP (див. Lavarel, CakePHP).

3

Що Joomla! має визначити постійний у кореневому файлі та перевірити, чи визначено те саме у включених файлах.

defined('_JEXEC') or die('Restricted access');

інакше

можна зберігати всі файли поза доступом до запиту http, розміщуючи їх поза каталогом веб-кореневих файлів, як рекомендують більшість фреймворків, таких як CodeIgniter.

або навіть помістивши.



3

Моя відповідь дещо відрізняється підходом, але включає багато відповідей, наданих тут. Я рекомендую багатогранний підхід:

  1. .htaccess та обмеження Apache точно
  2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

ОДНАКdefined or die підхід має ряд недоліків. По-перше, це справжній біль у припущеннях перевірити та налагодити. По-друге, це передбачає жахливо, нудотно нудне рефакторинг, якщо ви передумаєте. "Знайдіть і замініть!" ти кажеш. Так, але наскільки ви впевнені, що скрізь все написано однаково, хммм? Тепер помножте це на тисячі файлів ... oO

А тут є .htaccess. Що станеться, якщо ваш код поширюється на сайти, де адміністратор не настільки ретельний? Якщо ви покладаєтесь лише на .htaccess, щоб захистити свої файли, вам також знадобиться a) резервна копія, b) коробка тканин, щоб висушити сльози, в) вогнегасник, щоб погасити полум'я у всій ненависті від людей. використовуючи свій код.

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

Що я пропоную:

  1. Перед будь-яким із ваших сценаріїв require('ifyoulieyougonnadie.php');( не include() і як заміна на defined or die)
  2. В ifyoulieyougonnadie.php, зробити деякі логіки речей - перевірку для різних констант, викликаючи сценарій, локальне тестування і такий - а потім реалізувати ваші die(), throw new Exception, 403, і т.д.

    Я створюю власну структуру з двох можливих точок входу - головного index.php (Joomla Framework) та ajaxrouter.php (мій фреймворк) - тому залежно від точки входу я перевіряю наявність різних речей. Якщо прохання ifyoulieyougonnadie.phpне надходити з одного з цих двох файлів, я знаю, що шенагігани проводяться!

    Але що робити, якщо я додам нову точку входу? Не хвилюйтесь. Я просто змінююсьifyoulieyougonnadie.php і я сортую, плюс "не знаходжу та замінюю". Ура!

    Що робити, якщо я вирішив перенести деякі зі своїх сценаріїв, щоб зробити інший фреймворк, який не має однакових констант defined()? ... Ура! ^ _ ^

Я виявив, що ця стратегія робить розвиток набагато веселішим і набагато менше:

/**
 * Hmmm... why is my netbeans debugger only showing a blank white page 
 * for this script (that is being tested outside the framework)?
 * Later... I just don't understand why my code is not working...
 * Much later... There are no error messages or anything! 
 * Why is it not working!?!
 * I HATE PHP!!!
 * 
 * Scroll back to the top of my 100s of lines of code...
 * U_U
 *
 * Sorry PHP. I didn't mean what I said. I was just upset.
 */

 // defined('_JEXEC') or die();

 class perfectlyWorkingCode {}

 perfectlyWorkingCode::nowDoingStuffBecauseIRememberedToCommentOutTheDie();

2

Якщо точніше, вам слід скористатися цією умовою:

if (array_search(__FILE__, get_included_files()) === 0) {
    echo 'direct access';
}
else {
    echo 'included';
}

get_included_files () повертає індексований масив, що містить імена всіх включених файлів (якщо файл виконувався, тоді він був включений, а його ім'я - у масиві). Отже, коли файл безпосередньо отримує доступ, його ім'я є першим в масиві, всі інші файли в масиві були включені.


1
<?php
if (eregi("YOUR_INCLUDED_PHP_FILE_NAME", $_SERVER['PHP_SELF'])) { 
 die("<h4>You don't have right permission to access this file directly.</h4>");
}
?>

розмістіть код вище вгорі доданого файлу php.

колишній:

<?php
if (eregi("some_functions.php", $_SERVER['PHP_SELF'])) {
    die("<h4>You don't have right permission to access this file directly.</h4>");
}

    // do something
?>

if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Попередження про безпеку приладу - прямий доступ заборонено! Ваш IP-запис зареєстровано ! <h3> '); // Зупинити подальше виконання} whre ~ - це роздільник
MarcoZen


1

Я знайшов це лише для php та незмінного рішення, яке працює як з http, так і з cli:

Визначте функцію:

function forbidDirectAccess($file) {
    $self = getcwd()."/".trim($_SERVER["PHP_SELF"], "/");
    (substr_compare($file, $self, -strlen($self)) != 0) or die('Restricted access');
}

Викличте функцію у файлі, до якого ви хочете запобігти прямий доступ до:

forbidDirectAccess(__FILE__);

Більшість з наведених вище рішень цього питання не працюють у режимі Cli.


де слід вводити URL у режимі CLI?
Твій здоровий глузд

Це просто запобігти запуску скрипта / включення php в режимі cli. Може бути корисним у проекті з кількома розробниками.
Ка.


1
<?php       
$url = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
  if (false !== strpos($url,'.php')) {
      die ("Direct access not premitted");
  }
?>

1

Зберігання файлів, що включають файли за межами веб-доступного каталогу, вже згадувалося кілька разів, і це, безумовно, хороша стратегія, де це можливо. Однак інший варіант, який я ще не бачив, згадайте: переконайтеся, що ваші файли включення не містять коду для запуску . Якщо ваші файли включають лише функції та класи та не мають іншого коду, окрім цього, вони будуть просто створювати порожню сторінку при прямому доступі до них.

У будь-якому випадку дозвольте прямий доступ до цього файлу з браузера: він нічого не зробить . Він визначає деякі функції, але жодна з них не викликається, тому жодна з них не працює.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

Це ж стосується файлів, які містять лише класи PHP, і нічого іншого.


Це все ще гарна ідея зберігати файли поза веб-каталогом, де це можливо.

  • Ви можете випадково дезактивувати PHP, і в цьому випадку ваш сервер може надсилати вміст файлів PHP до браузера, замість запуску PHP та надсилання результату. Це може призвести до протікання вашого коду (включаючи паролі бази даних, ключі API тощо).
  • Файли у веб-каталозі присідають на URL-адреси, які ви можете використовувати для свого додатка. Я працюю з CMS, який не може мати сторінку під назвою system, тому що це суперечить шляху, який використовується для коду. Мені це дратує.

0

Зробіть щось на кшталт:

<?php
if ($_SERVER['SCRIPT_FILENAME'] == '<path to php include file>') {
    header('HTTP/1.0 403 Forbidden');
    exit('Forbidden');
}
?>

Це не завадить завантажувати його у браузер.
UnkwnTech

0

Ви можете скористатися наведеним нижче способом, хоча у нього є недолік, оскільки його можна підробити, за винятком випадків, коли ви можете додати інший рядок коду, щоб переконатися, що запит надходить лише з вашого сервера, використовуючи Javascript. Ви можете розмістити цей код у розділі Тіло свого HTML-коду, тому помилка там відображається.

<?
if(!isset($_SERVER['HTTP_REQUEST'])) { include ('error_file.php'); }
else { ?>

Помістіть тут свій інший HTML-код

<? } ?>

Закінчіть так, тому вихід помилки завжди відображатиметься в розділі тіла, якщо саме так ви хочете.


Я розумію, що всім заголовкам серверів HTTP_ * не варто довіряти, тому вам краще не використовувати цей метод.
andreszs

0

Я пропоную не використовувати з $_SERVERміркувань безпеки.
Ви можете використовувати змінну, як $root=true;у першому файлі, що включає ще один.
і використовувати isset($root)на початку другого файлу, який буде включений.


0

Також ви можете зробити захист паролем каталогу та зберегти там усі свої PHP-скрипти, звичайно, крім файлу index.php, оскільки на момент включення пароля не потрібно, оскільки це буде потрібно лише для доступу до http. що це зробить, це також надати вам можливість отримати доступ до своїх скриптів у випадку, якщо ви цього хочете, оскільки у вас буде пароль для доступу до цього каталогу. вам потрібно буде встановити .htaccess файл для каталогу та .htpasswd файл для автентифікації користувача.

добре, ви також можете скористатися будь-яким із запропонованих вище рішень, якщо вам здається, що вам не потрібно нормально отримувати доступ до цих файлів, оскільки ви завжди можете отримати доступ до них за допомогою cPanel тощо.

Сподіваюся, це допомагає


0

Найпростіший спосіб - зберігати свої включення поза веб-каталогом. Таким чином сервер має доступ до них, але немає жодної зовнішньої машини. Єдина нижня сторона - вам потрібно мати доступ до цієї частини вашого сервера. Зворотний бік полягає в тому, що він не потребує налаштування, налаштування чи додаткового напруги коду / сервера.


0

Я не знайшов пропозиції з .htaccess настільки гарними, оскільки він може блокувати інший вміст у тій папці, до якого ви можете дозволити користувачеві отримати доступ, це моє рішення:

$currentFileInfo = pathinfo(__FILE__);
$requestInfo = pathinfo($_SERVER['REQUEST_URI']);
if($currentFileInfo['basename'] == $requestInfo['basename']){
    // direct access to file
}

0
if ( ! defined('BASEPATH')) exit('No direct script access allowed');

зробить роботу безперебійно


2
Скопіюйте пасту з CodeIgnitor. Це круто, але насправді нічого не робить самостійно. Значення BASEPATH const встановлюється у index.phpфайлі, який лежить внизу структури дерева. CI переписує URL-адреси, тому немає необхідності в прямому доступі до скриптів.
jimasun

я знаю, що немає необхідності, але якщо хтось намагатиметься це зробити
Варшаан

0

Додано попереднє згадане рішення з перевіркою версії PHP:

    $max_includes = version_compare(PHP_VERSION, '5', '<') ? 0 : 1;
    if (count(get_included_files()) <= $max_includes)
    {
        exit('Direct access is not allowed.');
    }

2
Я не дуже розумію, як це може перешкодити прямому доступу
Адам Ліндсей
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.