Django Cookiecutter Production Login Fails With No Explanation/Log

I am struggling to take my Django project live using Docker on DigitalOcean where I use Django cookiecutter. Everything works fine in development (where I don’t use Docker, but a simple virtualenv and a local instance of Postgres) But in production when I submit the login form, if there’s an error (the user cannot be authenticated) then I get the message produced by allauth, but if the login is successful, I get redirected to login page, unauthenticated and without any explanation/log.

It is 99.99% user (my) fault, but I am running out of options after 5 hours of struggling. I appreciate any help, and would be willing to provide more info depending on what you might need. Thanks.

Here’s the .env file I use in prod:

# PostgreSQL
POSTGRES_PASSWORD=db_pass
POSTGRES_USER=db_user

# General settings
DATABASE_URL=postgres://db_user:db_pass@postgres:5432/db_name
DJANGO_SETTINGS_MODULE=config.settings.production
DJANGO_SECRET_KEY=*********************
# DJANGO_ALLOWED_HOSTS=.example.com
# DJANGO_ADMIN_URL=

# AWS Settings
# DJANGO_AWS_ACCESS_KEY_ID=
# DJANGO_AWS_SECRET_ACCESS_KEY=
# DJANGO_AWS_STORAGE_BUCKET_NAME=

# Used with email
# DJANGO_MAILGUN_API_KEY=
# DJANGO_SERVER_EMAIL=

# Security! Better to use DNS for this task, but you can use redirect
DJANGO_SECURE_SSL_REDIRECT=False

# django-allauth
DJANGO_ACCOUNT_ALLOW_REGISTRATION=True

# Sentry
DJANGO_SENTRY_DSN=

[hasancansaral]

Oh stupid me. I was trying to serve over HTTP, but forgot to comment out CSRF_COOKIE_SECURE = True.

So making these for lines from:

# SESSION_COOKIE_SECURE = True
# SESSION_COOKIE_HTTPONLY = True
CSRF_COOKIE_SECURE = True
# CSRF_COOKIE_HTTPONLY = True

to:

# SESSION_COOKIE_SECURE = True
# SESSION_COOKIE_HTTPONLY = True
# CSRF_COOKIE_SECURE = True
# CSRF_COOKIE_HTTPONLY = True

resolved the issue. @jayfk Thank you for your time and @pydanny, thanks for pointing me at the right direction. I guessed it was a user fault. 😋

[hasancansaral]

@pydanny Thanks for your wishes, we are all safe now.

Here are the docker-compose logs django results:

django_1 | [2016-07-14 13:27:53 +0000] [9] [INFO] Starting gunicorn 19.6.0
django_1 | [2016-07-14 13:27:53 +0000] [9] [INFO] Listening at: http://0.0.0.0:5000 (9)
django_1 | [2016-07-14 13:27:53 +0000] [9] [INFO] Using worker: sync
django_1 | [2016-07-14 13:27:53 +0000] [12] [INFO] Booting worker with pid: 12
django_1 | [2016-07-14 13:27:53 +0000] [13] [INFO] Booting worker with pid: 13
django_1 | [2016-07-14 13:27:53 +0000] [14] [INFO] Booting worker with pid: 14
django_1 | [2016-07-14 13:27:53 +0000] [15] [INFO] Booting worker with pid: 15
django_1 | DEBUG 2016-07-14 13:28:00,238 base 14 140614911735552 Configuring Raven for host: <raven.conf.remote.RemoteConfig object at 0x7fe36b101cf8>
django_1 | INFO 2016-07-14 13:28:00,239 base 14 140614911735552 Raven is not configured (logging is disabled). Please see the documentation for more information.
django_1 | DEBUG 2016-07-14 13:28:01,338 base 15 140614911735552 Configuring Raven for host: <raven.conf.remote.RemoteConfig object at 0x7fe36b100d68>
django_1 | INFO 2016-07-14 13:28:01,339 base 15 140614911735552 Raven is not configured (logging is disabled). Please see the documentation for more information.
django_1 | DEBUG 2016-07-14 13:29:18,855 base 13 140614911735552 Configuring Raven for host: <raven.conf.remote.RemoteConfig object at 0x7fe36b101cc0>
django_1 | INFO 2016-07-14 13:29:18,856 base 13 140614911735552 Raven is not configured (logging is disabled). Please see the documentation for more information.
django_1 | DEBUG 2016-07-14 15:42:39,747 base 12 140614911735552 Configuring Raven for host: <raven.conf.remote.RemoteConfig object at 0x7fe36b100ba8>
django_1 | INFO 2016-07-14 15:42:39,748 base 12 140614911735552 Raven is not configured (logging is disabled). Please see the documentation for more information.

Following this is a couple of Invalid HTTP_HOSTS header ERRORs from regular port scans, I guess everything is pretty normal at this point.

Here is the output for docker-compose ps:

        Name                       Command               State              Ports            
--------------------------------------------------------------------------------------------
projectname_django_1     /entrypoint.sh /gunicorn.sh      Up                                  
projectname_nginx_1      nginx -g daemon off;             Up      443/tcp, 0.0.0.0:80->80/tcp 
projectname_postgres_1   /docker-entrypoint.sh postgres   Up      0.0.0.0:5432->5432/tcp      
projectname_redis_1      docker-entrypoint.sh redis ...   Up      6379/tcp                    

Again, I am assuming it to be normal (except for the port mapping on postgres service-which I changed to run on the host to see if it will make a difference, everything is as is).