【问题标题】:Caching of password-protected data using Varnish使用 Varnish 缓存受密码保护的数据
【发布时间】:2012-03-16 06:38:40
【问题描述】:

我只想将生成的资源提供给具有管理权限的用户,并且我希望 Varnish 为我缓存它,这样后端就不必在每次请求时都重新生成它。我也不想在后端执行缓存,因为我有 Varnish 用于此目的。

这是我的后端所做的伪代码:

if (authenticated(cookie)) 
{
    if (stale)
    {
        regenerate_and_send()
    }
    else
    {
         not_modified()
    }
}
else
{
     access_denied()
}

所以我正在考虑 Varnish 执行验证(条件 GET)并以“未修改”、“拒绝访问”或“200 OK”HTTP 状态响应后端(当然是在最后一种情况下重新生成资源)。

我需要 Varnish 将 cookie 传递到后端,但在将资源存储在缓存中时忽略 cookie,因此只存储一个副本。

我该怎么做?

执行验证和编写后端逻辑很容易。如何在 Varnish 中处理 cookie,以便它们不会影响缓存但仍会传递到后端?

【问题讨论】:

    标签: caching varnish


    【解决方案1】:

    默认情况下,如果请求有 cookie,Varnish 不会在缓存中查找,因此您必须编写自己的 vcl 配置文件。

    如果我正确理解了您的问题,相关资源可以提供给所有具有管理员权限的用户。这里的故事是;每个用户都有不同的会话 cookie,varnish 无法知道哪个会话 cookie 具有管理员权限。你可以(至少)做两件事:

    1. 如果用户获得管理员权限,请设置“admin=yourmagicstringhere”cookie。使 Varnish 能够验证魔术字符串是否正确,并相应地对资源的请求进行查找/获取。这有一些安全方面的缺点,但很有效。
    2. 总是将请求转发到后端(无需在缓存中查找/存储),如果用户是管理员权限,后端会生成一个 请求,即解决。作为 ESI 的替代方案,您可以让后端生成一些其他 OK 响应并重新启动,您可以在其中执行查找/获取/交付。

    【讨论】:

    • 我采用了 ESI 方法,它奏效了!谢谢你。至于重启方法 - 我认为很容易错误地引入重启循环。
    猜你喜欢
    • 1970-01-01
    • 2011-12-23
    • 1970-01-01
    • 2011-09-11
    • 2010-09-27
    • 2013-11-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多