上篇含全系列链接：传送门
前一篇文章主要实现了OAuth最开始的一步，跳转至平台账号，和一些乱七八糟为了工程化做的准备。这篇文章里会实现OAuth剩下的步骤，包括从认证码到令牌符再到用户信息。
之前的Nginx配置里已经先埋了个坑——在我们OAuth?？榈某跏蓟?，已经传了两个目前还没有用到的参数，token_endpoint 和 profile_endpoint，它们就对应着认证码换令牌符和令牌符取用户信息两个API：
init_by_lua_block {
require('oauth').init({
code_endpoint = 'https://github.com/login/oauth/authorize',
token_endpoint = 'https://github.com/login/oauth/access_token',
profile_endpoint = 'https://api.github.com/user',
client_id = 'client_id',
client_secret = 'client_secret',
redirect_uri = 'http://test.myoauth.com/auth-cb/github/login',
scope = 'user',
})
}
在OAuth的回调URL里，之前也定义了这么一段：
location /auth-cb/github/login {
content_by_lua_block {
return require('oauth').get_profile(ngx.var.arg_code)
}
}
里面的 ngx.var.arg_code 就是在OAuth平台跳转回来以后的临时认证码。现在可以先把 get_profile 函数改成下面这个样子，函数和对应的数据都被命名得非常直观：
-- in resty/lua/oauth.lua
function M.get_profile(code)
local token = get_token(code)
local profile = get_profile(token)
ngx.say(cjson.encode(profile))
end
注意 M.get_profile 挂在了 oauth.lua 这个?？橐┞冻隼吹娜衷砝?，和我们马上要定义的局部函数 get_token 和 get_profile 并不产生命名冲突。下面就是取令牌符和取用户令牌的请求逻辑，完全根据GitHub的OAuth流程文档来写，纯属无脑搬砖。
local resp = require('resp')
local requests = require('requests')
local function get_token(code)
local payload = {
client_id = _conf.client_id,
client_secret = _conf.client_secret,
code = code,
}
local status, body, err = requests.jpost(_conf.token_endpoint, cjson.encode(payload))
if not status then resp.fail(err, _conf.token_endpoint, ngx.HTTP_SERVICE_UNAVAILABLE)
else
if status ~= 200 then resp.fail(err, cjson.decode(body), status)
else return ngx.decode_args(body).access_token end
end
end
local function get_profile(token)
local status, body, err = requests.jget(
_conf.profile_endpoint, '',
{ Authorization = 'token ' .. token })
if not status then resp.fail(err, _conf.profile_endpoint, ngx.HTTP_SERVICE_UNAVAILABLE)
else
if status ~= 200 then resp.fail(err, cjson.decode(body), status)
else return cjson.decode(body) end
end
end
里面带了一点简单的错误处理逻辑，在出错的时候会记下对应的请求报文和API路径，全部都是来自以下这个简短的小工具?？椋?/p>
-- resty/lua/resp.lua
local cjson = require('cjson.safe')
cjson.encode_empty_table_as_object(false)
local M = {}
function M.fail(msg, detail, status)
if status then ngx.status = status end
ngx.say(cjson.encode({ msg = msg, detail = detail }))
if status then ngx.exit(status) end
end
return M
好了，现在代码的全貌已经出来了。试着跑一下……咦？出错了，返回Unavailable了？看一下日志，有这么一行：
XXXX/XX/XX XX:XX:XX [debug] 33#33: *34 [lua] requests.lua:53: jpost(): "no resolver defined to resolve \"github.com\""
问题出在哪儿呢？问题就在于，Nginx并不会自动做DNS查询，它的所有转发和请求都基于IP。我想这样的设计初衷应该是考虑到DNS解析时间比较不可控，不想让大量这样的请求占太多的网络IO。不过我们这个场景下DNS解析是刚需，没办法写死IP，解决办法就是在http block里加上这么一句 resolver 8.8.8.8;，让Nginx在读到基于域名请求的时候调用Google的DNS服务。
加好DNS resolver之后再试……又双叒叕不行？！再翻日志，这下是这个问题：
XXXX/XX/XX XX:XX:XX [error] 36#36: *36 lua ssl certificate verify error: (20: unable to get local issuer certificate), client: 172.17.0.1, server: , request: "GET /auth-cb/github/login?code=XXXXXXXXXXXXXXXXXXX
这个问题我第一次遇到也是一脸懵逼，放狗问了一下才知道，原来Nginx不但不解析域名，连HTTPS Cert也不会自动检查。解决方法也不麻烦，找到Linux发行版的根证书（必须是PEM格式的——我也不知道还有什么格式），用 lua_ssl_trusted_certificate 引进来，然后用 lua_ssl_verify_depth 定义一下证书查询最多经过几步（默认只查一次我也是醉了）。所以http block里在 init_by_lua_block 之前的配置就长这个样子：
http {
include /usr/local/openresty/nginx/conf/mime.types;
lua_package_path '$prefix/lua/?.lua;;';
lua_code_cache off;
resolver 8.8.8.8;
lua_ssl_verify_depth 10;
lua_ssl_trusted_certificate '/etc/ssl/certs/ca-certificates.crt';
init_by_lua_block {
...
}
为什么是查询的depth定为10？我瞎定的。为什么根证书的路径是这个？我根据Demo的发行版查的，Alpine放在这里，CentOS和Ubuntu可能都不是这个地方。
好啦，现在访问我们本地服务的OAuth认证URL，浏览器就会先返回302跳转到GitHub的认证页，登录并授权后GitHub就会把临时认证码再通过跳转发给浏览器，浏览器对我们的回调接口发起带临时认证码的请求，我们的服务后台拿到临时认证码后先发一个请求到GitHub去获取令牌符，然后再把令牌符放进Auth Header发起一个请求，GitHub就会告诉我们的服务这个用户到底是谁，有什么profile信息咯。现在拿到用户信息以后我们无脑用JSON丢给浏览器，但根据业务需要做用户的认证啊登记啊什么的，都不麻烦。
到此为止，我们就在OpenResty里实现了一个特别简单的OAuth 2认证流程咯。欢迎大家拍砖留言。
一般人我不告诉他：最近写得有点密集了，过两天会再多加一篇补遗，填上一个第一篇的作业中，阮老师博客里有人回复提到的坑（其实如果你注意到Dockerfile里最后一行装了一个到现在都没有提到过的session第三方库……）
