会话ID在重定向django & docker时被更改

ffscu2ro  于 2022-12-18  发布在  Docker
关注(0)|答案(2)|浏览(141)

我有一个Django和react项目。我使用Nginx和Gunicorn来运行这个应用程序。为了运行所有这些,我使用了docker。
在Django视图中,我设置了一个session变量,然后重定向到另一个视图,所以在重定向的视图中,当我试图访问session变量时,它不会被获取。

我使用默认的session来存储django_session表中的session,我也检查了一下,它正在获取django_session表中存储的session值,但是我真的不明白为什么它不能获取session值。
有线部分是在这里,在火狐它的工作,但在Chrome中没有。
通过运行Django的runserver命令,同一个项目正在我的本地(没有docker)运行。
下面是我的docker-compose.test.yml文件的外观

version: "3.8"

services:
    db:
        image: postgres:12.3
        ports:
          - "5432:5432"
        env_file:
          - ./env/.env.dev.db
        volumes:
          - postgres_data:/var/lib/postgresql/data/
        networks:
          - backend
    app:
        build:
          context: .
          dockerfile: ./docker/test-env/app-docker/Dockerfile
          args:
              - REACT_APP_API_URL=http://127.0.0.1
        volumes:
          - app_static_files:/app/static

        command: >
          /bin/sh -c
          "python manage.py migrate
          && python manage.py collectstatic --no-input
          && gunicorn -w 4 --bind 0.0.0.0:8000 app.wsgi
          "
        env_file:
          - ./env/.env.dev.db
          - ./env/.env.dev
        ports:
          - "8000:8000"
        depends_on:
          - db
        networks:
          - backend
    nginx:
        build:
          context: .
          dockerfile: ./docker/test-env/nginx/Dockerfile
        ports:
          - "80:80"
          - "443:443"
        volumes:
          - app_static_files:/project_static_files
        depends_on:
          - app
        networks:
          - backend

volumes:
    postgres_data:
    app_static_files:
networks:
    backend:

这是我的应用程序Docker文件的样子。

# BUILD FRONT END
FROM node:12.17.0-alpine3.11 as frontend

ARG REACT_APP_API_URL
ENV REACT_APP_API_URL $REACT_APP_API_URL

WORKDIR /app
COPY ./app/front_end/app-frontend/ /app

RUN npm install

RUN npm run build

# APPLICATION
FROM python:3.8.3-slim

ENV PATH="/app:${PATH}"

WORKDIR /app

RUN apt-get update && apt-get install -y gcc libxml2-dev libxmlsec1-dev pkg-config  \
   && apt-get -y install libsasl2-dev libldap2-dev libssl-dev libxmlsec1-openssl python3-dev

COPY ./app/ /app

COPY --from=frontend /app/build /app/front_end/noa-frontend/

RUN pip install -r production_requirements.txt --no-cache-dir

下面是Nginx配置

server {
    listen 80;
    server_name $server_addr;
    access_log  /var/log/nginx/example.log;

    location /static/ {
        autoindex off;
        alias /project_static_files/;
    }

    location / {
        proxy_pass http://app:8000;
        proxy_pass_request_headers on;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Port $server_port; 
    }
}

请有人请帮帮我,我在网上找不到任何关于这方面的东西。
我正在做的这个项目

  1. Windows 10专业版
  2. Docker版本19.03.8,构建版本afacb 8b
    1.停靠-合成版本1.25.5,构建版本8a 1c 60 f6

更新日期:

我也尝试了Django的runserver来测试它是否能在docker容器中与Django的runserver一起工作。但是没有,我在Chrome中遇到了同样的问题,但在Firefox中它工作正常:(
在我看到的错误中,Chrome只传递了csrftoken,而Firefox同时传递了csrftoken和sessionid。
传递到Chrome

的Cookie
传递到Firefox

的Cookie

yqlxgs2m

yqlxgs2m1#

我知道怎么回事了。
我有一个环境变量文件。在其中,我设置了下面几行
会话_Cookie_安全_瓦尔=0
CSRF_COOKIE_瓦尔=0
DEV_ENV=1
在www.example.com上settings.py我有

SESSION_COOKIE_SECURE = bool(int(os.environ.get("SESSION_COOKIE_SECURE_VAL")))
CSRF_COOKIE_SECURE = bool(int(os.environ.get("CSRF_COOKIE_SECURE_VAL")))

所以0代表False,1代表True。即使我为SESSION_COOKIE_SECURE和CSRF_COOKIE_SECURE设置了0(False),它还是取1,即True(我真的不知道为什么它取1作为默认值,即使我为它们设置了环境值)
在Django文档中,它被描述为

因此,我所做的就是更改www.example.com文件中的逻辑settings.py,如下所示

if not bool(int(os.environ.get("DEV_ENV", default=1))):
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True

我的开发环境不是HTTPS,所以请检查它是否不是开发环境,然后不要设置SESSION_COOKIE_SECURE和CSRF_COOKIE_SECURE(在这种情况下,默认情况下两者都为False)
我不知道为什么Firefox能够在此设置下设置cookie。
如果有更好的答案,请回答。
如果有人面临同样的问题,我希望这会有所帮助。

vqlkdk9b

vqlkdk9b2#

我也遇到过类似的问题,我在不同的端口上运行两个django项目
8000
以及
9000
为了解决这个问题,我在另一个上输入了localhost:8000和127.0.0.1:9000。
这解决了我的问题,我猜是因为浏览器现在把它当作完全不同的域,所以会话不再是问题了

相关问题