ordertut10: now we use access_by_lua instead of auth_request in the config samples for the "satisfy" directive.

Author: agentzh

zh-cn/02-NginxDirectiveExecOrder10.tut

@@ -146,22 +146,16 @@ B 都在 C<access> 阶段注册了与访问控制相关的处理程序，那就
         satisfy all;
 
         deny all;
-        auth_request /auth;
+        access_by_lua 'ngx.exit(ngx.OK)';
 
         echo something important;
     }
 
-    location /auth {
-        internal;
-        echo OK;
-    }
-
 这里，我们在 C</test> 接口中同时配置了 L<ngx_access> 模
-块和 L<ngx_auth_request> 模块，这样 C<access> 阶
+块和 L<ngx_lua> 模块，这样 C<access> 阶
 段就有这两个模块一起来做检验工作。其中，语句 C<deny all> 会让 L<ngx_access>
-模块的处理程序在这里总是会拒绝访问，而语句 C<auth_request /auth>
-则总是允许访问（因为 C</auth> 接口永远返回 C<200> 成功码的响应
-）。当我们通过 L<ngx_core/satisfy> 指令配置了 C<all>
+模块的处理程序在这里总是会拒绝访问，而语句 C<access_by_lua 'ngx.exit(ngx.OK)'>
+则总是允许访问。当我们通过 L<ngx_core/satisfy> 指令配置了 C<all>
 方式时，就需要 C<access> 阶段的所有模块都通过验证，但不幸的是，这里
 L<ngx_access> 模块总是会拒绝访问，所以整个请求就会被拒：
 
@@ -187,6 +181,6 @@ any>，则结果则会完全不同：
     something important
 
 即请求反而最终通过了验证。这是因为在 C<any> 方式下，C<access>
-阶段只要有一个模块通过了验证，就会认为请求整体通过了验证，而在上例中，L<ngx_auth_request>
-模块总是会通过验证的。
+阶段只要有一个模块通过了验证，就会认为请求整体通过了验证，而在上例中，L<ngx_lua>
+模块的 L<ngx_lua/access_by_lua> 语句总是会通过验证的。