部署Nginx Plus作为API网关：Nginx

HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。

# Error responses 
 error_page 404 = @400; # Invalid paths are treated as bad requests 
 proxy_intercept_errors on; # Do not send backend errors to the client 
 include api_json_errors.conf; # API client friendly JSON error responses 
 default_type application/json; # If no content-type then assume JSON 

顶级API网关配置包括一个定义如何处理错误响应的部分。

第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此(可选)行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。

第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。

完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。

error_page 400 = @400; 
location @400 { return 400 '{"status":400,"message":"Bad request"}n'; } 
  
error_page 401 = @401; 
location @401 { return 401 '{"status":401,"message":"Unauthorized"}n'; } 
  
error_page 403 = @403; 
location @403 { return 403 '{"status":403,"message":"Forbidden"}n'; } 
  
error_page 404 = @404; 
location @404 { return 404 '{"status":404,"message":"Resource not found"}n'; } 

有了这种配置，客户端对无效URI的请求就会收到以下响应。

$ curl -i https://api.example.com/foo  
HTTP/1.1 400 Bad Request  
Server: nginx/1.13.10  
Content-Type: application/json  
Content-Length: 39  
Connection: keep-alive  
  
{"status":400,"message":"Bad request"} 

实施身份验证

在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。有关基于IP地址的访问控制列表(ACL)，数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证方法。

API密钥身份验证

API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。

openssl rand -base64 18 7B5zIqmRGXmrJTFmKa99vcit 

在顶级API网关配置文件api_gateway.conf的第6行，我们包含一个名为api_keys.conf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。

map $http_apikey $api_client_name { 
 default ""; 
  
 "7B5zIqmRGXmrJTFmKa99vcit" "client_one"; 
 "QzVV6y1EmQFbbxOfRCwyJs35" "client_two"; 
 "mGcjH8Fv6U9y3BVF9H3Ypb9T" "client_six"; 
} 

API密钥在块中定义。 map指令有两个参数。第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量($ api_client_name)并将其设置为第一个参数与键匹配的行上的第二个参数的值。

例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!