• 数据合法性检测
    • JSON 数据格式
    • 关键字段编码为 HEX，长度不定
    • TABLE 内部字段类型

    数据合法性检测

    对用户输入的数据进行合法性检查，避免错误非法的数据进入服务，这是业务系统最常见的需求。很可惜 Lua 目前没有特别好的数据合法性检查库。

    坦诚我们自己做的也不够好，这里只能抛砖引玉，看看大家是否有更好办法。

    我们有这么几个主要的合法性检查场景：

    • JSON 数据格式
    • 关键字段编码为 HEX（0-9，a-f，A-F），长度不定
    • TABLE 内部字段类型

    JSON 数据格式

    这里主要是 json decode 时，可能抛出异常的问题。我们已经在 json 解析的异常捕获 一章中详细说明了问题本身以及解决方法，这里就不再重复。

    关键字段编码为 HEX，长度不定

    HEX 编码，最常见的存在有 MD5 值等。他们是由 0-9，A-F（或 a-f）组成。笔者把使用过的代码版本逐一罗列，并进行性能测试。通过这个测试，我们不仅仅可以收获参数校验的正确写法，以及可以再次印证一下效率最高的匹配，应该注意什么。

    1. require "resty.core.regex"
    4. -- 纯 lua 版本，优点是兼容性好，可以适用任何 lua 语言环境
    5. function check_hex_lua( str )
    6.     if "string" ~= type(str) then
    7.         return false
    8.     end
    10.     for i = 1, #str do
    11.         local ord = str:byte(i)
    12.         if not (
    13.             (48 <= ord and ord <= 57) or
    14.             (65 <= ord and ord <= 70) or
    15.             (97 <= ord and ord <= 102)
    16.         ) then
    17.             return false
    18.         end
    19.     end
    20.     return true
    21. end
    23. -- 使用 ngx.re.* 完成，没有使用任何调优参数
    24. function check_hex_default( str )
    25.     if "string" ~= type(str) then
    26.         return false
    27.     end
    29.     return ngx.re.find(str, "[^0-9a-fA-F]") == nil
    30. end
    32. -- 使用 ngx.re.* 完成，使用调优参数 "jo"
    33. function check_hex_jo( str )
    34.     if "string" ~= type(str) then
    35.         return false
    36.     end
    38.     return ngx.re.find(str, "[^0-9a-fA-F]", "jo") == nil
    39. end
    42. -- 下面就是测试用例部分代码
    43. function do_test( name, fun )
    44.     ngx.update_time()
    45.     local start = ngx.now()
    47.     local t = "012345678901234567890123456789abcdefABCDEF"
    48.     assert(fun(t))
    49.     for i=1,10000*300 do
    50.         fun(t)
    51.     end
    53.     ngx.update_time()
    54.     print(name, "\ttimes:", ngx.now() - start)
    55. end
    57. do_test("check_hex_lua", check_hex_lua)
    58. do_test("check_hex_default", check_hex_default)
    59. do_test("check_hex_jo", check_hex_jo)

    把上面的源码在 OpenResty 环境中运行，输出结果如下：

    1. ➜  resty test.lua
    2. check_hex_lua   times:1.0390000343323
    3. check_hex_default   times:5.1929998397827
    4. check_hex_jo    times:0.4539999961853

    不知道这个结果大家是否有些意外，check_hex_default 的运行效率居然比 check_hex_lua 要差。不过所幸的是我们对正则开启了 jo 参数优化后，速度上有明显提升。

    引用一下 ngx.re.* 官方 wiki 的原文：在优化性能时，o 选项非常有用，因为正则表达式模板将仅仅被编译一次，之后缓存在 worker 级的缓存中，并被此 Nginx worker 处理的所有请求共享。缓存数量上限可以通过 lua_regex_cache_max_entries 指令调整。

    课后小作业：为什么测试用例中要使用 ngx.update_time() 呢？好好想一想。
    课后小作业：在测试用例里面加了一行 require "resty.core.regex"。试试去掉这一行，重新跑下程序。结果怎么样？

    TABLE 内部字段类型

    当我们接收客户端请求，除了指定字段的特殊校验外，我们最常见的需求就是对指定字段的类型做限制了。比如用户注册接口，我们就要求对方姓名、邮箱等是个字符串，手机号、电话号码等是个数字类型，详细信息可能是个图片又或者是个嵌套的 TABLE。

    例如我们接受用户的注册请求，注册接口示例请求 body 如下：

    1. {
    2.     "username":"myname",
    3.     "age":8,
    4.     "tel":88888888,
    5.     "mobile_no":13888888888,
    6.     "email":"***@**.com",
    7.     "love_things":["football", "music"]
    8. }

    这时候可以用一个简单的字段描述格式来表达限制关系，如下：

    1. {
    2.     "username":"",
    3.     "age":0,
    4.     "tel":0,
    5.     "mobile_no":0,
    6.     "email":"",
    7.     "love_things":[]
    8. }

    对于有效字段描述格式，数据值是不敏感的，但是数据类型是敏感的，只要数据类型能匹配，就可以让我们轻松不少。

    来看下面的参数校验代码以及基本的测试用例：

    1. function check_args_template(args, template)
    2.     if type(args) ~= type(template) then
    3.       return false
    4.     elseif "table" ~= type(args) then
    5.       return true
    6.     end
    8.     for k,v in pairs(template) do
    9.       if type(v) ~= type(args[k]) then
    10.         return false
    11.       elseif "table" == type(v) then
    12.         if not check_args_template(args[k], v) then
    13.           return false
    14.         end
    15.       end
    16.     end
    18.     return true
    19. end
    21. local args = {name="myname", tel=888888, age=18,
    22.     mobile_no=13888888888, love_things = {"football", "music"}}
    24. print("valid   check: ", check_args_template(args, {name="", tel=0, love_things={}}))
    25. print("unvalid check: ", check_args_template(args, {name="", tel=0, love_things={}, email=""}))

    运行一下上面的代码，结果如下：

    1. ➜  resty test.lua
    2. valid   check: true
    3. unvalid check: false

    可以看到，当我们业务层面需要有 email 地址但是请求方没有上送，这时候就能检测出来了。大家看到这里也许会笑，尤其是从其他成熟 web 框架中过来的同学，我们这里的校验可以说是比较粗糙简陋的，很多开源框架中的参数限制，都可以做到更加精确的限制。

    如果你有更好更优雅的解决办法，欢迎与我们联系。