Jump to content
xisto Community
Mordent

Error Pages?

Recommended Posts

I'm having a little trouble getting my head around the best way of protecting various files in my site. Essentially, the basic structure of the site is such that virtually everything is done via the main index page, which then includes various other source pages (depending on the $_GET["page"] variable), so if the page index.php?page=archive is loaded then it includes the archive source page from elsewhere in the site.Naturally this points towards not allowing the visitors to access the source pages themselves (which are stored in the relative directory /src/pages). So far the best method I've had of making sure this isn't the case is to use a header redirect to point towards the full URL of index.php?page=error_forbidden if a certain variable isn't defined (which I define in index.php). This seems to work fairly well, but it doesn't strike me as being a particularly elegant solution, and I wondered if a neater one was available using file permissions and .htaccess? For those wondering, I've already tried using the header redirects to point towards the directory one up (namely to ../index.php), which all in turn point one directory further upwards, but apparently you're not allowed to redirect the user that many times. ;) Any advice on the matter would be appreciated, as it rubs me the wrong way to do it with a full URL (especially as I'm developing it locally first, so would have to change every pages redirection location when I eventually upload it).

Share this post


Link to post
Share on other sites

Just a little bump, as this issue is still unresolved. As I haven't got the domain I want for my website yet, I can't test my ideas too easily (all development currently done locally), and as I never really spent too long looking at how file permissions and so on work I'm at a bit of a loss as to how to use them to do what I want (see previous post). What sort of file permissions would I need to have on the files (and the directory) to allow the server to see what it needs to see (namely able to include the files) but not let them be accessed directly? 700 (using the fairly standard notation)?

Share this post


Link to post
Share on other sites

What do you mean by "elegant solution"? Comparing string variables (names of the files you're going to include) is neat enough to me, general visitors don't really look into the web url, if that is what you mean.

And about CHMOD permissions, I think it is 600, even though it MIGHT vary. If that is set up correctly, it would show an error even when including (require_once) it with PHP, unless you make some kind of modification in the way PHP picks the file up.

Again, just tell us what you mean by "elegant solution" ;)

BTW, a good "secure" way to do this, would be the following:

$pageurl= "http://"; // https:// if secure server set$pageurl .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];if ($pageurl!= "http://URL.com/SCRIPT.php")die("This page is only to be seen from the main webpage located at X.com");

That's it.
Edited by Pankyy (see edit history)

Share this post


Link to post
Share on other sites

Bringing this topic to the surface again, your suggestion is not dissimilar to how I'm currently doing it. Rather than checking the page URL, I check whether a variable has been defined. If not, redirect them to the "you're not allowed to be here!" page. It works, no doubt about it, but contrary to the saying "if it's not broken, don't fix it" I'm looking for an alternative.Why am I posting here now? Because after all this time I've still not found out much about file permissions. By their very nature they sound like the exact sort of thing that I should be using for doing this. I've still yet to work out exactly how they work - and yet to get the domain for the hosting, but that's slightly besides the point - and would certainly appreciate a bit of help on the matter.Essentially, I'm after the file permissions (in the format ###, with # as a number) required to have a file with the following access attributes:Cannot be written to in any way (all changes must be made by uploading a new file to the server with the same name and replacing it)The server can access the file for include purposes (i.e. the server can read it)The file cannot be directly accessed by the user (generates a 403 error, which I will deal with using a .htaccess file)Any ideas? Other than writing some sort of test scripts for this, I figured this would be the easiest way of getting an answer. Is it in fact possible using file permissions, or is the current method (or the one suggested by Pankyy) a better solution?

Share this post


Link to post
Share on other sites

Place all the files you want to access without any one else accessing it outside of public_html (i.e. one level up from it). The permissions can be whatever you want for that directory that you are storing the files in, as no one will be able to access the files therein without at least FTP or CPanel access or through your script, of course.

Share this post


Link to post
Share on other sites

here is what I use to overcome this problem.
the baseurl is defined in the config file.
If it does not exist when the include file is accessed, then someone is trying to link directly to the file, so a redirect to the index.php is done.

<?php/*  *	This is the main content module. *	This page is included by index.php. */// Redirect if this page was accessed directly:if (!defined('BASE_URL')) {	// Need the BASE_URL, defined in the config file:	require_once ('../includes/config.inc.php');		// Redirect to the index page:	$url = BASE_URL . 'index.php';	header ("Location: $url");	exit;	} // End of defined() IF.?>

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.