PHPインクルードファイルへの直接アクセスを禁止する


166

インクルードとして排他的に使用するphpファイルがあります。したがって、含まれているのではなく、URLを入力して直接アクセスした場合、実行する代わりにエラーをスローしたいと思います。

基本的に、phpファイルで次のようにチェックを行う必要があります。

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

これを行う簡単な方法はありますか?


10
die()の代わりに 'header( "HTTP / 1.1 404 File Not Found"、404);をテストする必要があります。出口;'。これにより(少なくともApacheでは)、サーバーは通常の404ページを返します。
gnud

PHPに含まれるファイルで直接アクセスを無効にするために説明した2つの簡単な方法を次に示し
Faruque Ahamed Mollick

回答:


173

一般的な「完全に制御できるかどうかにかかわらず、Apacheサーバー上で実行されているPHPアプリ」の最も簡単な方法は、インクルードをディレクトリに入れ、.htaccessファイルでそのディレクトリへのアクセスを拒否することです。人々がグーグルの手間を省くために、Apacheを使用している場合は、アクセスできないようにしたいディレクトリの「.htaccess」というファイルにこれを配置します。

Deny from all

実際にサーバーを完全に制御している場合(最近では、この答えを最初に書いたときよりも小さなアプリでも一般的です)、最善の方法は、Webサーバーがサービスを提供しているディレクトリの外側に保護するファイルを貼り付けることです。そのため、アプリがにある場合は、/srv/YourApp/ファイルを提供するようにサーバーを設定し、インクルードを/srv/YourApp/app/に配置して、/srv/YourApp/includes文字通り、それらにアクセスできるURLがないようにします。


1
おかげで、私はこのアプリを実行するサーバーを完全に制御できるため、これが私が行った答えです。
Alterlife 2009年

24
サーバーを完全に制御できる場合は、仮想ホスト構成ファイルのディレクトリディレクティブに構成を配置する方が適切です。Apacheは起動時に一度だけそれを読み取り、.htaccessはすべてのアクセスで読み取られ、サーバーの速度を低下させます
Eineki

22
この回答の一部として.htaccessファイルの例を用意しておくと便利です。
Graham Lea

7
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
Dracorat 2012

11
@James:また、Stack Overflowが「plz send teh codez」サイトである必要があると誰もが感じるわけではありません。それが質問に明確に答えるなら、それは良い答えです。必要のない例を提供することは、コピーアンドペーストのコーディングを促進するだけです。
チャック

188

これだけを含めたいページに追加します

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

それを含むページに追加します

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

3
私は本当に速くタイプすることを学ぶ必要があります。これは、変数を使用してチェックする方法よりも安全であるため、私が提案する方法と同じです。一部のPHPセットアップでは、変数をオーバーライドできる場合があります。
Mark Davidson、

3
これは、いくつかの「主流」アプリケーションがそれを処理する方法です。私はJoomlaがこの方法でそれを行うことを知っています。また、Wiki、Wordpress、その他も同様に考えています。
UnkwnTech 2009年

1
おそらくメッセージはハッカーにとってあまりにも役に立ちます(実際のユーザーはこれらのページを見つけられません)。リダイレクトヘッダーを送信して、phpの処理を停止するだけで済みます。
バンディ2009年

7
404ヘッダーを送信して終了するだけです-エラーページは通常の404ページと同じに見えます(少なくともApacheでは)。
gnud

4
@ Smile.Hunter:これは、インクルード/ライブラリスクリプトファイルを直接表示するアクセスをブロックすることに関するもので、答えは機能します。彼らsomefile.phpがあなたのサーバーで作成し、それにあなたの定義を追加した場合、それでも彼らはインクルードファイルに直接アクセスできません。ライブラリファイルを「含める」ことができますが、サーバーでファイルを作成し、定義/含めるスクリプトを理解するのに十分な場合は、他の問題があり、そもそも定義を使用して独自のファイルを書き込むことができません。 。
Jamesの

114

ファイルが含まれている場合と直接アクセスされている場合(主にprint()vs return())で異なる動作をする必要があるファイルがあります。変更されたコードを次に示します。

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

アクセスされるファイルは常にインクルードファイルであるため、== 1です。  


12
インクルードされたファイルの数をチェックするというのは、実際には地獄のようなものです。どちらが良いのだろうか:定義を使用するか、この方法を使用するか?これは自己完結型のようです。
Akoi Meexx

誰もがこれを思いつくのを見たのは初めてです。なぜなら、それは可能な限り自己完結しているようであり、関連付けられていると想定されているもの(特定の定数や.htaccessによって禁止された特定の場所)。綺麗な。
神保ジョニー

.htaccessを使用してすべての.phpファイルをブロックすることは、同じディレクトリに直接またはJavaScriptでさえ呼び出す必要のあるファイルが存在する可能性があるため、常に可能ではない場合があるため、これは本当にクールです。この素晴らしいアイデアをありがとう!
Anuj 2012

3
これはPHP5以降でのみ機能します。1の代わりに0をもう一度比較したいPHP5以前
jmucchiello

これは本当に賢いソリューションであり、ブロックするだけでなく、直接アクセスを制御することができます-それが私の好みです。私は通常、ファイル自体に単体テストを含めます。これにより、このifステートメントで単体テストをラップできます。それがどのように効率的なワンダー...
whiteatom

34

ファイルへの直接アクセスを防ぐ最良の方法は、ファイルをWebサーバーのドキュメントルートの外(通常は1レベル上)に置くことです。それらを含めることはできますが、誰かがhttpリクエストを通じてそれらにアクセスする可能性はありません。

私は通常、すべての方法で、ブートストラップファイルを除いて、すべてのPHPファイルをドキュメントルートの外側に配置します。ドキュメントルートにある単独のindex.phpは、Webサイト/アプリケーション全体のルーティングを開始します。


3
これが可能であれば、これは優れたソリューションです。私は最近、共有ウェブホストでの作業を開始する必要があり、すべてがdocroot内にある必要があるという多くの問題の1つを発見しました。
ボーシメンセン、

3
私が使用したすべてのホスティングプロバイダーで、ドキュメントルートの1つ上のレベルに(正確に)アクセスできました。
エランガルペリン

3
一部のホスト(私の現在のホストを含​​む)では、ドメインを任意のフォルダーにポイントできます。
ダイナ

1
これも良い代替案です.. preg_match-> if(preg_match( "〜globalfile \ .php〜i"、$ _SERVER ['PHP_SELF']))を使用する{die( '<h3 style = "color:red">アプライアンスセキュリティアラート-直接アクセスは許可されていません!IPが記録されました!<h3> '); //以降の実行を停止します}
MarcoZen 2017年

その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:Webサーバー固有の構成

ほとんどのサーバーでは、個々のファイルまたはディレクトリに権限を割り当てることができます。すべてのインクルードをそのような制限されたディレクトリに配置し、それらを拒否するようにサーバーを構成することができます。

たとえば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リンクはWebサイトのアドレスシステムの範囲外であるため、ユーザーはフォルダーの外部にあるファイルを要求できません。
  • phpサーバーはファイルシステムにネイティブにアクセスするため、必要な権限を持つ通常のプログラムと同じようにコンピューター上のファイルにアクセスできます。
  • このディレクトリにインクルードファイルを配置することで、ユーザーがホットリンクを拒否している間に、phpサーバーがそれらにアクセスできるようにすることができます。
  • Webサーバーのファイルシステムアクセス構成が適切に行われていなくても、この方法により、これらのファイルが誤って公開されるのを防ぐことができます。

私の正統でないコーディング規約を許してください。どんなフィードバックでもありがたいです。


私は2の数字が好き
Baim Wrong

26

Chuckのソリューションの代替(または補足)は、.htaccessファイルに次のようなものを挿入して、特定のパターンに一致するファイルへのアクセスを拒否することです。

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

.inc.phpを使用する方が良いと思います。これは一般的な慣例です
Lis

14

実際、私のアドバイスは、これらすべてのベストプラクティスを実行することです。

  • ドキュメントをウェブルート外に置くか、ウェブサーバーによるアクセスを拒否されたディレクトリに置く
  • 非表示のドキュメントがチェックする可視ドキュメントの定義を使用します。
      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

これにより、ファイルが何らかの理由で誤った場所に置かれた場合(誤ったFTP操作)、ファイルは引き続き保護されます。


8

私は一度この問題を抱えていて、解決しました:

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

しかし、理想的な解決策は、別のanwserで言及されているように、ファイルをWebサーバーのドキュメントルートの外側に配置することです。


7

あなたは1つの入り口でアプリケーションを構築するほうがいいです、すなわちすべてのファイルはindex.phpから到達されるべきです

これをindex.phpに配置します

define(A,true);

このチェックは、リンクされた各ファイルで実行する必要があります(requireまたはincludeを介して)

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

最も簡単な方法は、includeを呼び出す変数をファイルに設定することです。

$including = true;

次に、含まれているファイルで、変数を確認します

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

2
register_globalsがオンの場合、これは危険です。
jmucchiello 2009年

25
register_globalsがオンの場合、PHPは危険です。
David Precious

3

.htaccessの方法以外にも、Ruby on Railsなど、さまざまなフレームワークで有用なパターンを見てきました。それらはアプリケーションのルートディレクトリに別個のpub /ディレクトリを持ち、ライブラリディレクトリはpub / と同じレベルのディレクトリにあります。このようなもの(理想的ではありませんが、あなたはアイデアを得ます):

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

ドキュメントルートとしてpub /を使用するようにWebサーバーを設定します。これにより、スクリプトの保護が強化されます。ドキュメントルートから必要なコンポーネントをロードするためにアクセスすることはできますが、インターネットからコンポーネントにアクセスすることはできません。セキュリティ以外の利点は、すべてが1か所にあることです。

この設定は、「アクセスが許可されていません」というメッセージが攻撃者への手掛かりであるため、含まれているすべてのファイルにチェックを作成するだけではなく、ホワイトリストに基づいていないため、.htaccess構成よりも優れています。 lib /、conf /などのディレクトリには表示されません。


久しぶりに、上記で説明したモデルはMVC(モデル-ビュー-コントローラー)モデルと呼ばれているとコメントしたいと思います。よろしければ、Googleをチェックして、回答にさらに情報を追加してください。また、MVCはRuby on RailsおよびASP.NETアプリケーションだけでなく、PHPもサポートします(Lavarel、CakePHPを参照)。

3

なんとJoomla!ルートファイルで定数を定義し、インクルードファイルで定数が定義されているかどうかを確認します。

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

さもなければ

CodeIgniterのようなほとんどのフレームワークが推奨するように、すべてのファイルをwebrootディレクトリの外に置くことで、すべてのファイルをhttpリクエストの範囲外に保つことができます。

または、インクルードフォルダー内に.htaccessファイルを配置してルールを記述することで、直接アクセスを防ぐことができます。



3

私の答えはアプローチが多少異なりますが、ここで提供される多くの答えが含まれています。私は多面的なアプローチをお勧めします:

  1. 確かに.htaccessとApacheの制限
  2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

ただし、このdefined or dieアプローチには多くの欠点があります。第一に、テストとデバッグに使用する仮定の本当の痛みです。第二に、それはあなたがあなたの心を変えるならば、恐ろしいほど、心が何となく退屈なリファクタリングを含みます。「検索して置き換える!」あなたは言う。はい、でも、どこでもまったく同じように書かれていることをどれだけ確信していますか。それを数千のファイルで乗算します... oO

そして、.htaccessがあります。管理者がそれほど慎重ではないサイトにコードを配布するとどうなりますか?ファイルの保護に.htaccessのみに依存している場合は、a)バックアップ、b)涙を乾かすためのティッシュボックス、c)人からのすべてのヘイトメールで炎を消すための消火器あなたのコードを使用して。

だから私は質問が「最も簡単」を求めていることを知っていますが、これが要求するものはより「防御的なコーディング」だと思います。

私が提案するのは:

  1. スクリプトの前require('ifyoulieyougonnadie.php');ではなく include()、の代わりとしてdefined or die
  2. ではifyoulieyougonnadie.php、いくつかのロジックを実行します-さまざまな定数、呼び出しスクリプト、localhostテストなどを確認してからdie(), throw new Exception, 403、を実装します。

    2つの可能なエントリポイント(メインのindex.php(Joomlaフレームワーク)とajaxrouter.php(私のフレームワーク))を使用して独自のフレームワークを作成しています。へのリクエストifyoulieyougonnadie.phpがこれらの2つのファイルのいずれかから来ていない場合、私はシェナンガンが行われていることを知っています!

    しかし、新しいエントリポイントを追加するとどうなりますか?心配ない。変更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> '); //以後の実行を停止}〜が区切り文字である場合
MarcoZen '30

1

次のコードは、Flatnux CMS(http://flatnux.altervista.org)で使用されています。

if ( strpos(strtolower($_SERVER['SCRIPT_NAME']),strtolower(basename(__FILE__))) )
{
    header("Location: ../../index.php");
    die("...");
}

1

私は、httpとcliの両方で動作するこのphp専用の不変のソリューションを見つけました:

関数を定義します。

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

への直接アクセスを禁止するファイル内の関数を呼び出します。

forbidDirectAccess(__FILE__);

この質問に対する上記の解決策のほとんどは、Cliモードでは機能しません。


それはCLIモードでURLを入力することになっていますか?
常識

これは、CLIモードでPHPスクリプト/インクルードが起動しないようにするためのものです。複数の開発者がいるプロジェクトで役立ちます。
カー。

1
if (basename($_SERVER['PHP_SELF']) == basename(__FILE__)) { die('Access denied'); };

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

1

インクルードファイルをWebのアクセス可能なディレクトリの外に保存することは何度か言及されており、可能な場合は確かに優れた戦略です。ただし、まだ言及していない別のオプションについては、インクルードファイルに実行可能なコードが含まれていないことを確認してください。インクルードファイルが関数とクラスを定義するだけで、それ以外のコードがない場合は、直接アクセスしたときに空白ページが生成されます。

ブラウザからこのファイルへの直接アクセスを許可してください何もしません。いくつかの関数が定義されていますが、どれも呼び出されないため、実行されません。

<?php

function a() {
    // function body
}

function b() {
    // function body
}

同じことが、PHPクラスのみを含み、他の何も含まないファイルにも適用されます。


可能な場合は、ファイルをWebディレクトリの外部に置くことをお勧めします。

  • 誤ってPHPを非アクティブ化する可能性があります。その場合、サーバーがPHPを実行して結果を送信する代わりに、PHPファイルのコンテンツをブラウザーに送信する可能性があります。これにより、コード(データベースパスワード、APIキーなど)がリークする可能性があります。
  • Webディレクトリ内のファイルは、アプリで使用する可能性のあるURLをスクワットしています。と呼ばれるページを持つことができないCMSをsystem使用します。これは、コードに使用されるパスと競合するためです。私はこれがいらいらします。

0

次のようなことをしてください:

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

これにより、ブラウザへのロードが妨げられることはありません。
UnkwnTech 2009年

0

次のメソッドを使用することもできますが、別のコード行を追加してリクエストがJavascriptを使用してサーバーからのみであることを確認できる場合を除いて、偽造できるため、欠陥があります。このコードをHTMLコードのBodyセクションに配置すると、エラーが表示されます。

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

ここに他のHTMLコードを配置します

<? } ?>

このように終了してください。そうすれば、エラーの出力は常にbodyセクション内に表示されます。


すべてのHTTP_ *サーバーヘッダーが信頼されるわけではないので、この方法は使用しない方がいいと思います。
andreszs

0

$_SERVERセキュリティ上の理由からを使用しないことをお勧めします。別の
変数$root=true;を含む最初のファイルのような変数を使用できます。含まれる2番目のファイルの先頭で
使用isset($root)します。


0

また、ディレクトリをパスワードで保護し、そこにすべてのphpスクリプトを保持することもできます。もちろん、index.phpファイルを除いて、インクルード時にパスワードはhttpアクセスにのみ必要なので、パスワードは必要ありません。また、そのディレクトリにアクセスするためのパスワードがあるため、必要に応じてスクリプトにアクセスするオプションも提供します。ディレクトリの.htaccessファイルと、ユーザーを認証するための.htpasswdファイルを設定する必要があります。

また、cPanelなどから常にアクセスできるため、通常はこれらのファイルにアクセスする必要がないと思われる場合は、上記のソリューションを使用することもできます。

お役に立てれば


0

最も簡単な方法は、インクルードをWebディレクトリの外に保存することです。そうすれば、サーバーはそれらにアクセスできますが、外部のマシンはアクセスできません。唯一の欠点は、サーバーのこの部分にアクセスできる必要があることです。利点は、セットアップ、構成、または追加のコード/サーバーのストレスを必要としないことです。


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 2016年

私は必要がないことを知っていますが、
誰か

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
これが直接アクセスをどのように防ぐことができるのか、本当に理解していません
Adam Lindsay
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.