© 2008 bombusbee.com, all rights reserved ::: Print this page ::: Close window
Forcing Users Through index.php

November 27, 2001

::: Introduction :::

One of the basic concepts of Fusebox is that the users' requests to the server are always routed through a single file. Most commonly that file is index.php or whatever the default file happens to be.

Another of the basic concepts in Fusebox is that the coder can put very little code in a file and include it within the switch block, making fuses that are very modular and easy to reuse. These fuses are usually separated into functional groupings with a prefix: qry_ is for a file that queries or otherwise interacts with the database, act_ is for a file that performs business logic or other action on data, and dsp_ is for a file that displays content to the user. Fusebox 3.0 has also introduced the fbx_ prefix, which designates a file that is essential to the core of Fusebox.

Now that some of those standards are established and people are using them in a vast variety of sites, it makes sense that once a person figured out the system, they could guess what your files are names and try to view them independent of the rest of the application. For example, say a user figures out that you have a file called qry_getCreditCardNumbers.php. I'm not sure why you would have such a fuse, but for argument's sake, I'm pretty sure you would not want that "out there". Perhaps a better example is fbx_Settings.php: this is where you would typically set server passwords for your database or LDAP server or something of the like.

So the question remains: how do we make sure users do not have access to those files, or really any file except the "Fusebox" — index.php?


::: Forcing the Fusebox :::

In ColdFusion, where Fusebox began, the typical solution to this problem is to use a special file called Application.cfm which automatically runs at the beginning of each HTTP request. In PHP, we can create a file that function similarly by using the php setting for auto_prepend_file. This can be set in either the PHP.ini file (if you have access to it), or, on Apache servers, you can set this in the .htaccess file:

  
php_value auto_prepend_file Application.php


Now every time there is a request for a PHP document, the Application.php file will get run first. The next question is: what goes into the Application.php file? Well, anything that restricts the user to running the file(s) you want them to have access to. For this example, I will show how to restrict access to the index.php file:

  
<?php
if(!preg_match("/index\.php$/i"$HTTP_SERVER_VARS["SCRIPT_NAME"])) {
    
header("Location: index.php");
    exit;
}
?>


Voila! You can only access the index.php file now! Problem solved.

Or is it?


::: Fine Tuning :::

The example shown on the previous page will indeed work just fine. You can stop here if it has solved your problem. However, there are some ways to fine tune this concept and make your coding a little simpler.

The first "problem" with the previous example is that if you have subdirectories, as we commonly do in Fusebox, you will have to include an Application.php file for every subdirectory of the main application. That is just fine if that is the way you want to do things, but it can get a little unwieldy, especially if you want to make a change to the way your Application.php file works. The solution I have used for that problem is to locate a single Application.php file by using an absolute path to it in the .htaccess file:

  
php_value auto_prepend_file /home/htdocs/Application.php


That way you only have to maintain one file. If you do have a non-Fusebox subdirectoy, you can override the auto_prepend_file setting in that directory's .htaccess file.

(added 11/30/2001) You can also avoid this problem by setting a global include directory, and placing the Application.php file in there. Then you will not have to put an Application.php file in every directory, nor will you have to set the path to it absolutely. In fact, if you want to mimic the functionality of Application.cfm from ColdFusion, set the auto_prepend_file to "Application.php", and set your global include directory to your application's root. There are more details in the new PHP Tricks article from November 30, 2001.

Is this the only way to force people through the index? No, not really...


::: An Alternative Method :::

Some people, myself included, have experimented with placing the entire Fusebox application above the web root. That is a great way to keep people from accessing files that they should not access, since the server will not have anything publicly accessible except for an index.php file that include()s the Fusebox application. Something like this would go in your public index.php:

  
<?php
include("../FuseRoot/index.php");
?>


However, I personally stay away from that solution because of the issues it raises with thing like images, CSS files, or external JavaScript files. A great thing about Fusebox is the ability to create modular "circuit applications" that you can plug into any larger application to add the functionality of that circuit to another project. On this site the "search" circuit would be really simple to pull out and drop into another application (hmm... not a bad idea: watch the downloads section for a plug-and-play search circuit app...). When you push everything above the web root, any images or JavaScript includes or other files that the browser needs to access independent of your PHP scripts have to be pulled out and dropped into the public section in order for them to function properly. Personally, I use images and CSS on my sites quite a bit, but if you do not, this might be the perfect, cross-platform solution for you.

Another option is to further leverage your web server's abilities and restrict access to only the index.php file at the server level (instead of the script level, as we did with the Application.php file). I have not experimented with this at all, but there should be a way to set Apache to only allow access to index.php, and no other files.


::: Conclusion :::

There are a couple of ways to restrict users' access to your application's innards. My favorite is still the Application.php method, but it may not be yours, and it may not be mine forever. Perhaps you will move your application above the web root, or perhaps you will be the one to come up with an even cleaner solution that all the rest of us adopt.

Whatever the solution, the main side effect of this restriction is tighter security in general. What could be so bad about that? End of article


© 2008 bombusbee.com, all rights reserved ::: Print this page ::: Close window