webserver层进行校验，直接告诉应用层校验结果，就可以避免上面的问题。openresty+Lua就是这样一种webserver上安全、稳定、高性能的实现，并且开发成本低的方案。

新建，access.lua 代码:

local secretkey='1234567890abcdefghi'

if ngx.var.cookie_uid == nil or ngx.var.cookie_username == nil or ngx.var.cookie_token ==nil then

ngx.req.set_header("Check-Login", "NULL")

return

end

local ctoken = ngx.md5('uid:' .. ngx.var.cookie_uid .. '&nickname:' ..ngx.var.cookie_username .. '&secretkey:' .. secretkey)

if ctoken == ngx.var.cookie_token then

ngx.req.set_header("Check-Login", "Yes")

else

ngx.req.set_header("Check-Login", "No")

end

return

2、

php生成 cookie页面：

$uid = 123;

$username = “jincon”

$secretkey = “1234567890abcdefghi”;

setcookie(“uid”,$uid,time()+3600);

setcookie(“username”,$username,time()+3600);

setcookie(“secretkey”,$secretkey,time()+3600);

?>

判断是否校验成功：

if($_SERVER[‘HTTP_CHECK_LOGIN’]){

$uid = $_COOKIE[‘uid’];

$username = $_COOKIE[‘username’];

}

?>

3、nginx 的修改：

location ~ [^/]\.php(/|$) {

#添加 lua 加载。

access_by_lua_file "/usr/local/openresty/nginx/lua/test.lua";

fastcgi_pass unix:/dev/shm/php-cgi.sock;

fastcgi_index index.php;

include fastcgi.conf;

}

可能有的人说 HTTP 这样开头不都是可以伪造的嘛，是可以伪造，

但是了解 nginx 和 lua 执行流程就知道了，这里是不能伪造的，提供测试代码，你试试可能伪造：

$ch = curl_init();

$url = "http://192.168.1.58/test.php";

$header = array(

'Check-Login:No'

);

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_HTTPHEADER, $header);

curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);

$page_content = curl_exec($ch);

curl_close($ch);

echo $page_content;

?>

附nginx+lua 处理流程(自己看吧)：

Nginx 处理每一个用户请求时，都是按照若干个不同阶段(phase)依次处理的，而不是根据配置文件上的顺序。

Nginx 处理请求的过程一共划分为 11 个阶段，按照执行顺序依次是

post-read、server-rewrite、find-config、rewrite、post-rewrite、 preaccess、access、post-access、try-files、content、log.

post-read:读取请求内容阶段Nginx读取并解析完请求头之后就立即开始运行例如模块ngx_realip就在post-read阶段注册了处理程序，它的功能是迫使Nginx认为当前请求的来源地址是指定的某一个请求头的值。

server-rewrite

Server请求地址重写阶段

当 ngx_rewrite 模块的set配置指令直接书写在 server 配置块中时，基本上都是运行在 server-rewrite 阶段

find-config配置查找阶段这个阶段并不支持Nginx模块注册处理程序，而是由Nginx核心来完成当前请求与location配置块之间的配对工作。

rewrite

Location请求地址重写阶段

当 ngx_rewrite 模块的指令用于 location 块中时，便是运行在这个 rewrite 阶段。

另外，ngx_set_misc(设置md5、encode_base64等) 模块的指令，还有 ngx_lua 模块的 set_by_lua 指令和 rewrite_by_lua 指令也在此阶段。

post-rewrite

请求地址重写提交阶段

由 Nginx 核心完成 rewrite 阶段所要求的“内部跳转”操作,如果 rewrite 阶段有此要求的话。

preaccess访问权限检查准备阶段标准模块ngx_limit_req和ngx_limit_zone就运行在此阶段，前者可以控制请求的访问频度，而后者可以限制访问的并发度。

access访问权限检查阶段标准模块ngx_access、第三方模块ngx_auth_request以及第三方模块ngx_lua的access_by_lua指令就运行在这个阶段。配置指令多是执行访问控制性质的任务，比如检查用户的访问权限，检查用户的来源IP地址是否合法

post-access

访问权限检查提交阶段

主要用于配合 access 阶段实现标准 ngx_http_core 模块提供的配置指令 satisfy 的功能。

satisfy all(与关系)

satisfy any(或关系)

try-files配置项try_files处理阶段专门用于实现标准配置指令try_files的功能如果前N-1个参数所对应的文件系统对象都不存在，try-files阶段就会立即发起“内部跳转”到最后一个参数(即第N个参数)所指定的URI.

content内容产生阶段Nginx的content阶段是所有请求处理阶段中最为重要的一个，因为运行在这个阶段的配置指令一般都肩负着生成“内容”并输出HTTP响应的使命。

log日志模块处理阶段记录日志