如何使用Varnish缓存RESTful API,但仍然使用HMAC签名/验证每个请求？

Question

我有兴趣使用Varnish缓存/限制/等响应我正在创建的RESTful API.我可能过于松散地使用术语/首字母缩略词"HMAC",但我的意思是每个API API请求都应包含一个标题,其中包含客户端通过散列部分请求(包括时间戳)计算的哈希值共享秘密.然后,服务器使用来自请求的相同成分计算此相同的散列,并确定请求是否有效并应响应.

这很好用,但现在我想使用Varnish来缓存我的API响应.HMAC的性质要求每个请求计算散列以验证用户是谁,但返回的实际响应是相同的 - 因此API调用的内容非常容易缓存.

我想要的(我假设这可以实现,我只是不知道如何)是将身份验证任务传递给后端,以某种方式告诉Varnish"是的,继续并响应此请求"或"不,不要回复此请求"然后从那里让Varnish确定是否可以从缓存中提供请求.

更理想的情况是,做一些稍微更美好的事情,并允许Varnish自己处理身份验证,或者将HMAC处理传递到比后端更快的东西.例如,API可能将客户端密钥/公钥存储在redis缓存中,然后Varnish可能实际使用Redis中的值计算哈希本身.

Answer 1

您应该能够通过使用两个Varnish 模块在 Varnish VCL代码（Varnish 配置语言）中实现更高级的解决方案：

• Redis vmod来获取密钥。
• 用于计算/处理 HMAC 的Varnish Digest 模块。

这两个模块都在生产中使用，如模块目录中所列。

如果 Varnish 在 VCL 中处理身份验证，您可以让 Varnish 缓存您的 API 后端响应并仅针对经过身份验证的请求传递它。

如果 HMAC 实现需要请求正文：

正如Gridfire 在他/她的回答中指出的那样，Varnish 无法访问请求正文。我们可以/不应该从后端/应用程序发送 HTTP 标头中的完整请求正文。

但是，我们可以在 HTTP 标头中发送完整请求正文的哈希/摘要。与生成输出（标记|数据|任何内容）相比，后端哈希的计算应该可以忽略不计。AFAICT 只要散列/摘要和 HMAC 健壮，并且摘要很长（256 位或更多），这种方法就不应该有密码/实际缺点。像往常一样建议进行性能测试。