I'm not able to login to Django using uwsgi and nginx on AWS. I looked at this similar question, but I believe I have a different issue, since I'm using up-to-date versions of uwsgi (2.0.18) and nginx (1.10.3). Ubuntu is 16.04.
There's no error message on the login screen. It works fine on development, and it (or something similar) worked fine in the past. There's nothing written to the Django logs.
The nginx log shows:
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"
The uwsgi log shows:
[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)
UPDATE: With a bit of research, the second line above is the key one. The POST /userAuth/login/ succeeds, or at least does what it needs to in redirecting to GET /core/. The GET /core/ request, however, is never processed (never makes it to the appropriate view) but is intercepted at some point and returns another redirect back to /userAuth/login/. The GET /userAuth/login/ fully succeeds, leaving the user back where they started.
uwsgi's demo.mysite.ini is:
[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's demo.mysite is:
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;
}
}
The view is just django.contrib.auth.views.login and the form from the login template is:
<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>
Any ideas appreciated!
The problem was that I was using http, but had SESSION_COOKIE_SECURE set to True. Thus no sessionid cookie was being passed. Turns out it was more similar to this question, which involved SESSION_COOKIE_DOMAIN, than the one I pointed to originally.