Django логин не работает с uwsgi / nginx - PullRequest
Новая
       8

Django логин не работает с uwsgi / nginx

0 голосов
/ 15 апреля 2020

Я не могу войти в Django, используя uwsgi и nginx в AWS. Я посмотрел на этот похожий вопрос , но я считаю, что у меня другая проблема, так как я использую современные версии uwsgi (2.0.18) и nginx (1.10.3). Ubuntu - 16.04.

На экране входа в систему нет сообщений об ошибках. Он отлично работает при разработке, и он (или что-то подобное) работал хорошо в прошлом. В журналы Django ничего не записано.

В журнале nginx показано: 

98.207.204.72 - - [15/Apr/2020:11:34:57 -0700] "POST /userAuth/login/ HTTP/1.1" 302 0 "http://demo.mysite.com/userAuth/login/?next=/core/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
98.207.204.72 - - [15/Apr/2020:11:34:57 -0700] "GET /core/ HTTP/1.1" 302 0 "http://demo.mysite.com/userAuth/login/?next=/core/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
98.207.204.72 - - [15/Apr/2020:11:34:57 -0700] "GET /userAuth/login/?next=/core/ HTTP/1.1" 200 593 "http://demo.mysite.com/userAuth/login/?next=/core/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"

В журнале uwsgi показано: 

[pid: 5692|app: 0|req: 4/4] 98.207.204.72 () {52 vars in 1105 bytes} [Wed Apr 15 11:34:57 2020] POST /userAuth/login/ => generated 0 bytes in 21 msecs (HTTP/1.1 302) 8 headers in 517 bytes (1 switches on core 0)
[pid: 5692|app: 0|req: 5/5] 98.207.204.72 () {46 vars in 928 bytes} [Wed Apr 15 11:34:57 2020] GET /core/ => generated 0 bytes in 0 msecs (HTTP/1.1 302) 4 headers in 135 bytes (1 switches on core 0)
[pid: 5692|app: 0|req: 6/6] 98.207.204.72 () {46 vars in 971 bytes} [Wed Apr 15 11:34:57 2020] GET /userAuth/login/?next=/core/ => generated 1047 bytes in 3 msecs (HTTP/1.1 200) 6 headers in 360 bytes (1 switches on core 0)

ОБНОВЛЕНИЕ: с помощью немного исследований, вторая строка выше является ключевой. POST / userAuth / login / завершается успешно или, по крайней мере, делает то, что нужно для перенаправления в GET / core /. GET / core / запрос, однако, никогда не обрабатывается (никогда не попадает в соответствующий вид), но в какой-то момент перехватывается и возвращает другое перенаправление обратно в / userAuth / login /. GET / userAuth / login / полностью завершается успешно, оставляя пользователя, с которого он начал.

demo.mysite.ini uwsgi: 

[uwsgi]
user = /home/user
base = %(user)/Mysite
projectName = mysite
regionName = demo
project = %(base)/%(projectName)
region = %(base)/%(regionName)

chdir = %(base)
home = %(user)/MysiteVenv
module = %(regionName).wsgi:application

master = true
processes = 1

socket = %(region)/%(projectName).sock
chmod-socket = 666
vacuum = true

plugins = logfile
logger = file:%(base)/%(regionName)/var/log/uwsgi.log

nginx demo.mysite : 

server {
    listen 80;

    server_name demo.mysite.com;


    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/user/Mysite;
    }

    location /media/ {
        root /home/user/Mysite/demo;
    }

    location / {
        include         uwsgi_params;
        uwsgi_pass      unix:/home/user/Mysite/demo/mysite.sock;
    }
}

Представление просто django .contrib.auth.views.login и форма из шаблона входа: 

<form method="post" action="{{ url('userAuth:login') }}">
  {% csrf_token %}
  <table>
    <tr>
      <td>{{ form.username.label_tag() }}</td>
      <td>{{ form.username }}</td>
    </tr>
    <tr>
      <td>{{ form.password.label_tag() }}</td>
      <td>{{ form.password }}</td>
    </tr>
  </table>

  <input type="submit" value="login" />
  {% if next %}
    <input type="hidden" name="next" value="{{ next }}" />
  {% else %}
    <input type="hidden" name="next" value="/core/" />
  {% endif %}
</form>

Любые идеи приветствуются!

1 Ответ

0 голосов
/ 18 апреля 2020

Проблема заключалась в том, что я использовал http, но для SESSION_COOKIE_SECURE было установлено значение True. Таким образом, сессионный повар ie не проходил. Оказывается, это было больше похоже на этот вопрос , который включал SESSION_COOKIE_DOMAIN, чем тот, на который я указывал первоначально.

...