前段时间写了个关于手机应用的api,一直是用的query_string这种地址,而且还是根据一个act参数来区分所有的动作,这种让开发人员看起来比较费眼。本来想改写为“?c=controller&m=method&type=3&id=1” 这种形式,利用m参数来载入文件并进行实例化,后来看了sina weibo api 是对地址进行了路由。也决定跟风对地址路由。本来CI框架自己自带路由效果,但是因为考虑是写api,想写的比较纯粹一点。
支持默认控制器(index)和方法(index):
index.php
index.php/controller
index.php/controller/method
index.php/controller/method/prarme1/value1
index.php/controller/method/param1/value1/param2/value2.....
具体类如下:
<?phpdefine('MODULE_DIR', './classes/');
$APP_PATH= str_replace($_SERVER['DOCUMENT_ROOT'], '', __FILE__);
$SE_STRING=str_replace($APP_PATH, '', $_SERVER['REQUEST_URI']); //计算出index.php后面的字段 index.php/controller/methon/id/3
$SE_STRING=trim($SE_STRING,'/');
//echo $SE_STRING.'<br>';
//这里需要对$SE_STRING进行过滤处理。
$ary_url=array(
'controller'=>'index',
'method'=>'index',
'pramers'=>array()
);
//var_dump($ary_url);
$ary_se=explode('/', $SE_STRING);
$se_count=count($ary_se);
//路由控制
if($se_count==1 and $ary_se[0]!='' ){
$ary_url['controller']=$ary_se[0];
}else if($se_count>1){//计算后面的参数,key-value
$ary_url['controller']=$ary_se[0];
$ary_url['method']=$ary_se[1];
if($se_count>2 and $se_count%2!=0){ //没有形成key-value形式
die('参数错误');
}else{
for($i=2;$i < $se_count;$i=$i+2){
$ary_kv_hash=array(strtolower($ary_se[$i])=>$ary_se[$i+1]);
$ary_url[pramers]=array_merge($ary_url[pramers],$ary_kv_hash);
}
}
}
$module_name=$ary_url['controller'];
$module_file=MODULE_DIR.$module_name.'.class.php';
//echo $module_file;
$method_name=$ary_url['method'];
if(file_exists($module_file)){
include($module_file);
$obj_module=new $module_name(); //实例化模块m
if(!method_exists($obj_module, $method_name)){
die('方法不存在');
}else{
if(is_callable(array($obj_module, $method_name))){ //该方法是否能被调用
//var_dump($ary_url[pramers]);
$get_return=$obj_module->$method_name($ary_url[pramers]); //执行a方法,并把key-value参数的数组传过去
if(!is_null($get_return)){ //返回值不为空
var_dump($get_return);
}
}else{
die('该方法不能被调用');
}
}
}
else
{
die('模块文件不存在');
}
?>
但泄露了实际路径的后果是不堪设想的,对于某些入侵者,这个信息可是非常重要,而事实上现在有很多的服务器都存在这个问题。有些网管干脆把PHP配置文件中的display_errors设置为Off来解决(貌似我们就是这样做的),但本人认为这个方法过于消极。
有些时候,我们的确需要PHP返回错误的信息以便调试。而且在出错时也可能需要给用户一个交待,甚至导航到另一页面。那么,有啥解决办法呢?
set_error_handler()
PHP从4.1.0开始提供了自定义错误处理句柄的功能函数set_error_handler(),但很少数脚本编写者知道。set_error_handler这个函数可以很好地防止错误路径泄露,当然还有其它更多的作用。
可以用来屏蔽错误。 出现错误一来会把一些信息暴漏给用户,极有可能成为黑客攻击你网站的工具。 二来让用户觉得你的水平很挫。
可以记下错误的信息, 及时发现一些生产环境的出现的问题。
可以做相应的处理, 出错的时候可以显示跳转到预先定义好的出错页面,提供更好的用户体验。
可以作为调试工具, 一些时候必须在生产环境调试一些东西, 但又不想影响正在使用的用户。
set_error_handler的使用方法如下:
string set_error_handler ( callback error_handler [, int error_types])
现在我们就用自定义的错误处理把实际路径过滤掉。假设有一个变量$admin,我们是用来判断访问者是否是管理员的(可以通过IP或者登录的用户id来做这个判断)
//admin为管理员的身份判定,true为管理员。
//自定义的错误处理函数一定要有这4个输入变量$errno,$errstr,$errfile,$errline,否则无效。
function my_error_handler($errno,$errstr,$errfile,$errline)
{
//如果不是管理员就过滤实际路径
if(!admin)
{
$errfile=str_replace(getcwd(),"",$errfile);
$errstr=str_replace(getcwd(),"",$errstr);
}
switch($errno)
{
case E_ERROR:
echo "ERROR: [ID $errno] $errstr (Line: $errline of $errfile) \n";
echo "程序已经停止运行,请联系管理员。";
//遇到Error级错误时退出脚本
exit;
break;
case E_WARNING:
echo "WARNING: [ID $errno] $errstr (Line: $errline of $errfile) \n";
break;
default:
//不显示Notice级的错误
break;
}
}
这样就自定义了一个错误处理函数,那么怎么把错误的处理交给这个自定义函数呢?
// 应用到类
set_error_handler(array(&$this,"appError"));
//示例的做法
set_error_handler("my_error_handler");
so easy,这样,就可以很好地解决安全和调试方便的矛盾了。而且你还可以花点心思,使错误提示更加美观以配合网站的风格。
原作者给出了两点需要注意的地方,我也放出来吧,希望引起广大同胞们的注意:
1、E_ERROR、E_PARSE、E_CORE_ERROR、E_CORE_WARNING、 E_COMPILE_ERROR、E_COMPILE_WARNING是不会被这个句柄处理的,也就是会用最原始的方式显示出来。不过出现这些错误都是编 译或PHP内核出错,在通常情况下不会发生。
2、使用set_error_handler()后,error_reporting ()将会失效。也就是所有的错误(除上述的错误)都会交给自定义的函数处理。
最后,出一个示例
//先定义一个函数,也可以定义在其他的文件中,再用require()调用
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
//为了安全起见,不暴露出真实物理路径,下面两行过滤实际路径
$errfile=str_replace(getcwd(),"",$errfile);
$errstr=str_replace(getcwd(),"",$errstr);
switch ($errno) {
case E_USER_ERROR:
echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";
echo "Aborting...<br />\n";
exit(1);
break;
case E_USER_WARNING:
echo "<b>My WARNING</b> [$errno] $errstr<br />\n";
break;
case E_USER_NOTICE:
echo "<b>My NOTICE</b> [$errno] $errstr<br />\n";
break;
default:
echo "Unknown error type: [$errno] $errstr<br />\n";
break;
}
/* Don't execute PHP internal error handler */
return true;
}
//下面开始连接MYSQL服务器,我们故意指定MYSQL端口为3333,实际为3306。
$link_id=@mysql_pconnect("localhost:3333","root","password");
set_error_handler(myErrorHandler);
if (!$link_id) {
trigger_error("出错了", E_USER_ERROR);
}
<?php
$db_user = 'myuser';
$db_pass = 'mypass';
$db_host = '127.0.0.1';
$db = mysql_connect($db_host, $db_user, $db_pass);
?>
用户名及密码都是敏感数据,是需要特别注意的。他们被写在源码中造成了风险,但这是一个无法避免的问题。如果不这么做,你的数据库就无法设置用户名和密码进行保护了。
如果你读过http.conf(Apache的配置文件)的默认版本的话,你会发现默认的文件类型是text/plain(普通文本)。这样,如果db.inc这样的文件被保存在网站根目录下时,就引发了风险。所有位于网站根目录下的资源都有相应的URL,由于Apache没有定义对.inc后缀的文件的处理方式类型,在对这一类文件进行访问时,会以普通文本的类型进行返回(默认类型),这样访问权限就被暴露在客户的浏览器上了。
为了进一步说明这个风险,考虑一下一个以/www为网站根目录的服务器,如果db.inc被保存在/www/inc,它有了一个自已的URLhttp://example.org/inc/db.inc(假设example.org是主机域名)。通过访问该URL就可以看到db.inc以文本方式显示的源文件。无论你把该文件保存在/www哪个子目录下,都无法避免访问权限暴露的风险。
对这个问题最好的解决方案是把它保存在网站根目录以外的包含目录中。你无需为了达到包含它们的目的而把它们放至在文件系统中的特定位置,所有只要做的只是保证Web服务器对其有读取权限。因此,把它们放在网站根目录下是没有必要的风险,只要包含文件还位于网站根目录下,任何减少风险的努力都是徒劳的。事实上,你只要把必须要通过URL访问的资源放置在网站根目录下即可。毕竟这是一个公共的目录。
前面的话题对于SQLite数据库也有用。把数据库保存在当前目录下是非常方便的,因为你只要调用文件名而无需指定路径。但是,把数据库保存在网站根目录下就代表着不必要的风险。如果你没有采用安全措施防止直接访问的话,你的数据库就危险了。
如果由于外部因素导致无法做到把所有包含文件放在网站根目录之外,你可以在Apache配置成拒绝对.inc资源的请求。
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>
如果只是因为要举个例子而这么写的话,可以理解,毕竟大家学到了一些手段,但这个例子未免生硬了一点。实际上只要把该文件更名为db.inc.php就可以了。就好象房子破了个洞而不去修补,却在外面去造一个更大的房子把破房子套起来一样。
后面你还可以看到另外一种防止数据库访问权限暴露的方法,该方法对于共享服务器环境(在该环境下尽管文件位于网站根目录之外,但依然存在暴露的风险)非常有效。