@vary_on_cookie由于非Django cookie而失败

Question

在Django 1.5.6应用程序中，我遇到了缓存问题：

@vary_on_cookie
@cache_page(24 * 60 * 60, key_prefix=':1:community')
@rendered_with("general/community.html")
@allow_http("GET")
def community(request):
    ...
    return { ... }

在本地，缓存工作正常，但是当我在暂存阶段测试这个缓存时，@vary_on_cookie不起作用--我从正在执行的查询中可以看出，社区()是在随后对这个页面的调用中执行的。

我更新了本地环境中的设置，以使用与暂存相同的Redis缓存来消除这种差异，但是本地环境继续正确运行。

看看Redis缓存中的键，我可以看到问题所在--每次调用此页面时，都会向缓存中添加新的键。比较cache.keys('*community*')的输出

当地：

第一次致电社区网页：

[u'community:1:views.decorators.cache.cache_page.:1:community.GET.b528759dd79cf1c6b405290c0bc05e39.3b7d4c38ec8d92512a4a0847f4738298.en-us.America/New_York', 
u'community:1:views.decorators.cache.cache_header.:1:community.b528759dd79cf1c6b405290c0bc05e39.en-us.America/New_York']

第二次呼叫(同一用户)：

[u'community:1:views.decorators.cache.cache_page.:1:community.GET.b528759dd79cf1c6b405290c0bc05e39.3b7d4c38ec8d92512a4a0847f4738298.en-us.America/New_York', 
u'community:1:views.decorators.cache.cache_header.:1:community.b528759dd79cf1c6b405290c0bc05e39.en-us.America/New_York']

注意，在这两种情况下都有相同数量的键。

分期：

第一次致电社区网页：

[u'community:1:views.decorators.cache.cache_header.:1:community.b528759dd79cf1c6b405290c0bc05e39.en-us.America/New_York',     
u'community:1:views.decorators.cache.cache_page.:1:community.GET.b528759dd79cf1c6b405290c0bc05e39.559380b85dc0cdcf0ff25051df78987d.en-us.America/New_York']

第二次呼叫(同一用户)：

[u'community:1:views.decorators.cache.cache_header.:1:community.b528759dd79cf1c6b405290c0bc05e39.en-us.America/New_York', 
u'community:1:views.decorators.cache.cache_page.:1:community.GET.b528759dd79cf1c6b405290c0bc05e39.559380b85dc0cdcf0ff25051df78987d.en-us.America/New_York', 
u'community:1:views.decorators.cache.cache_page.:1:community.GET.b528759dd79cf1c6b405290c0bc05e39.6ec85abcc8a14d66800228bdccc537f0.en-us.America/New_York']

注意到缓存中添加了一个附加条目，尽管它是同一个用户！

我很困惑该从这里去哪。这两个环境都在使用SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'。暂存环境清楚地认识到，在所有其他方面，这都是同一个用户。在@vary_on_cookie中发生了什么，从而在分期方面产生了差异，而不是在本地？

我检查了所有的阶段和本地差异，仔细检查了我的自定义中间件，但是我不知道该看什么。任何想法，即使是对下一步的看法，将是非常感谢的。谢谢!

更新

我检查了django.utils.cache._generate_cache_key()，看看它如何生成缓存密钥的最后一个十六进制部分。我天真地以为它只是查看了Django自己的cookie(比如sessionid)，但我看到它使用了传递给的cookie的所有 --也就是说，Django和non。对我来说，这意味着来自谷歌分析和新遗迹的曲奇，我没有在本地运行。

for header in headerlist:  # headerlist = [u'HTTP_COOKIE']
        value = request.META.get(header, None) # the string of all cookies, for ex: __atuvc=39%7C17%2C8%7C18; csrftoken=dPqaXS6XVGp2UUvfhEW9kS6R6WPHQlE4; sessionid=j6a83wbsq1sez9bz75n0tzl4n884umg2'
        if value is not None:
            ctx.update(force_bytes(value))

这真的是真的吗！世界上所有使用@vary_on_cookie的Django站点都受到第三方cookie的阻碍？！

Answer 1

我创建了一个定制的装饰器，它可以破解headers来隔离用户的ID。(虽然它在发送回浏览器的响应中设置了Vary: DJANGO_USERID, Cookie，但它不包括实际的ID。)

我很感激对这个解决方案的任何反馈，因为它有点超出了我的Django舒适区。谢谢!

def vary_on_user(view):
    """                                                                                                                                                                                                     
    Adapted from django.views.decorators.vary_on_cookie                                                                                                                                                                                          
    """
    @wraps(view, assigned=available_attrs(view))
    def inner_func(request, *args, **kwargs):
        request.META['HTTP_DJANGO_USERID'] = request.user.id
        response = view(request, *args, **kwargs)
        patch_vary_headers(response, ('DJANGO_USERID',))
        return response
    return inner_func