TBH I prefer the original system - the problem with not specifying the includes within the file is that user data could be manipulated.
So say you have a simple script:
Code: Select all
$page = $_GET['id'];
include($page . '.php');
I can now pass in almost any value, including ?id=../../../usr/data/secretfile or anything else and include any file on your current system. For this reason matching an ID to a pre-defined page is safer - the user data either has a valid ID or its simply not used, or provokes an error.
So although your suggestion is more flexible - its more open to attack by bad people on the internet...
Of course if you filter and validate your dynamic ID, its still workable - it's not a bad system, you just need to be aware of the security implications of user input before you blindly trust it.
For example, assuming your ID must follow a very simple rule, e.g. it can only be alphanumeric (A-Za-z0-9) you can safely use:
Code: Select all
$page = $_GET['id'];
if(!ctype_alnum($page)) // check whether the ID contains only letters and numbers
{
trigger_error('Error: Invalid Page ID passed as URL parameter. This may have been a hacking attempt!', E_USER_ERROR); // create a custom error message and exit the script (E_USER_ERROR is a custom fatal error)
}
require('/path/to/mysite/' . $page . '.php');
You probably get the point by now I think - always filter that user input (users can change the ID in the url) to be certain its valid.
At this point even if the alphanumeric ID is incorrect - the use of require() instead of include() will create an error if the file does not exist.
You now have a safer script, producing errors, and not letting any user look for any other file on your system other than the directory you specify.
Concluding this long post - the first method that opened this thread is safer, the one you suggest is more flexible but only if correctly filtered for user input. So if you are making use of your method - please ensure you have the suggested filtering in place...