nginx 缓存工作错误,nginx 缓存认证系统,注销不起作用(在 DJANGO 上),如何修复?

nginx 缓存工作错误,nginx 缓存认证系统,注销不起作用(在 DJANGO 上),如何修复?

nginx 正在缓存所有内容,如果我登录系统,那么在缓存过期之前我无法再退出,因为我已从帐户注销,所以我需要知道如何删除 cookie 和会话!

默认情况下,Django 本身在退出时会删除 cookies 和 session,使用标准方法从开发人员的 django 中退出账号,我就用这个,如果在 nginx 上禁用缓存,那么一切都正常!

nginx 配置“/etc/nginx/nginx.conf”

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
    gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

proxy_connect_timeout 5;
proxy_send_timeout 10;
proxy_read_timeout 10;

proxy_buffering on;
proxy_buffer_size 16k;
proxy_buffers 24 16k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

proxy_temp_path /tmp/nginx/proxy_temp;
add_header X-Cache-Status $upstream_cache_status;
    proxy_cache_path /tmp/nginx/cache levels=1:2 keys_zone=one:100m;
proxy_cache_path /tmp/nginx/cache2 levels=1:2 keys_zone=two:100m;
proxy_cache one;
proxy_cache_valid any 30d;
proxy_cache_key $scheme$proxy_host$request_uri$cookie_US;

我的服务器配置

upstream theband {
  # fail_timeout=0 means we always retry an upstream even if it failed
  # to return a good HTTP response (in case the Unicorn master nukes a
  # ssingle worker for timing out).

  server unix:/webapps/theband/run/gunicorn.sock fail_timeout=0;
}

server {

    listen   80;
    server_name 207.154.232.99;
    expires 35d;
    client_max_body_size 4G;

    access_log /webapps/theband/logs/nginx-access.log;
    error_log /webapps/theband/logs/nginx-error.log;
    error_log /webapps/theband/logs/nginx-crit-error.log crit;
    error_log /webapps/theband/logs/nginx-debug.log debug; 
    location /static/ {
        alias   /webapps/theband/static/;
    }

    location /media/ {
        alias   /webapps/theband/media/;
    }
    location ~* ^(?!/media).*.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        alias /tmp/nginx/trash/trash_media;
        expires 35d;
        add_header Pragma public;
        add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        access_log off;
    }    
    location ~* ^(?!/static).*.(?:css|js|html)$ {
    root /tmp/nginx/trash/trash_static;
        expires 35d;
        add_header Pragma public;
        add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        access_log off;
    }     

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache one;
        proxy_cache_min_uses 1;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

        # an HTTP header important enough to have its own Wikipedia entry:
        #   http://en.wikipedia.org/wiki/X-Forwarded-For
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # enable this if and only if you use HTTPS, this helps Rack
        # set the proper protocol for doing redirects:
        # proxy_set_header X-Forwarded-Proto https;

        # pass the Host: header from the client right along so redirects
        # can be set properly within the Rack application
        proxy_set_header Host $http_host;

        # we don't want nginx trying to do something clever with
        # redirects, we set the Host: header above already.
        proxy_redirect off;

        # set "proxy_buffering off" *only* for Rainbows! when doing
        # Comet/long-poll stuff.  It's also safe to set if you're
        # using only serving fast clients with Unicorn + nginx.
        # Otherwise you _want_ nginx to buffer responses to slow
        # clients, really.
        #proxy_buffering off;

        # Try to serve static files from nginx, no point in making an
        # *application* server like Unicorn/Rainbows! serve static files.
        if (!-f $request_filename) {
            proxy_pass http://theband;
            break;
        }
    }
    error_page 404 /error_404.html;
    location = /error_404.html {
        root /webapps/theband/src/templates;
    }

    # Error pages
    error_page  500 502 503 504 /error_500.html;
    location = /error_500.html {
        root /webapps/theband/src/templates;
    }
}

答案1

我哭了,我花了很多时间来解决这个问题,虽然我知道问题是什么,以及大致如何解决它,但我只是添加了简单,简单的1行代码.... CARL我们不得不把这个proxy_pass http://theband;

请杀了我吧(...

好吧,这样做,特定 URL 的缓存将被禁用,并且对页面的访问将正常工作!

location /accounts/logout {
    proxy_no_cache 1;
    proxy_cache_bypass 1;
    add_header Last-Modified $date_gmt;
    add_header Cache-Control 'no-cache, must-revalidate, proxy-revalidate, max-age=0';
    if_modified_since off;
    expires -1;
    proxy_pass http://theband;
    etag off;

}

答案2

在 nginx 中,您可以为管理页面设置一个明确不缓存的位置,因此请尝试类似以下操作:

location /admin {
    expires -1;
    Cache-control no-cache;
}

应该可以做到。Django 也有标头控制扩展可以做同样的事情。Cloudflare 应该遵守这些标头,无需进行任何更改。

答案3

注销时,您需要设置一些不同的标头,以便 nginx 知道要使代理缓存过期。proxy_module 内容是导致“问题”的原因

Buffering can also be enabled or disabled by passing “yes” or “no” in the “X-Accel-Buffering” response header field. This capability can be disabled using the proxy_ignore_headers directive. nginx 代理模块

如果你还使用 Cloudflare,你还应该发送过期和缓存控制标头。你可以在 Django 中使用patch_response_headers。Cloudflare 将尊重这些。如果您使用全页缓存,则可以添加另一个 PageRule 以永不缓存管理员内容。全页缓存仅通过 PageRules 启用。

相关内容