debug_backtrace in PHP to prevent direct access to page/resource

[terungwa]

I am using the debug_backtrace() php function to prevent direct access to admin files.

i simply place the code below at the top of a page eg config.php and direct access via the browser is prevented.

 

Is it a safe practice or is there a better way of doing it?

<?php

debug_backtrace() || die ("Direct access to this resource is  forbidden");

?>

Thanks

[Ch0cu3r]

What! You do realise what debug_backtrace() does? Its an odd usage case.

 

If you wanting to prevent direct access to config.php (or any other php files) then move it/them outside of your document root. That is simplest approach.

 

Alternatively way could be to define a constant in your main script. Then In config.php you'd kill the script if thast constant does not exist. Example

 

start of coded in main script

<?php
// define constant
define('IN_APP', true);
include 'config.php';

...

Then in config.php do

<?php

// check if constant is not defined
if(!defined('IN_APP'))
   die('Direct access to this resource is forbidden');

When anyone directly access config.php the script will be killed and the forbidden message is displayed.

[Jacques1]

The question is: What are you trying to achieve? Why are you afraid of people accessing the scripts?

 

If bad things happen when people execute your scripts directly, then that's the problem. You cannot solve this by hiding them. You need to actually fix the scripts so that they only do what they're supposed to do. For example, a configuration script shouldn't do anything but define configuration values. Calling it directly should have no absolutely no effect. So why worry about it?

 

In fact, it's nonsense to tell people that access to some script is forbidden. What's the point of that? If you don't want anybody to access a resource, then this resource shouldn't exist at all. In other words, the scripts don't belong into the document root. If that's not an option, make your webserver yield a 404 response for all scripts except the public ones.

 

But again: Direct access to a script should never be a problem. The only valid reason for hiding a script is to create a clean API. And this requires a 404 response, not this “forbidden” stuff.