a year ago
Does anyone know if or why reading Django (DRF) sessions might fail behind a reverse proxy on Railway such as Caddy or Nginx but work locally? I am using django.contrib.sessions.backends.db
in my case.
0 Replies
a year ago
are you having gunicorn trust the proxy headers?
I will be honest, I don't think I have done that. Do you know where I can find documentation for this?
a year ago
add the flag --forwarded-allow-ips *
to your gunicorn start command
So when I run this I get an error:
Failed to find attribute 'application' in 'Core'.
I seen online that it may have something to do with the [wsgi.py](wsgi.py)
file but I am not quite sure. Here is my [wsgi.py](wsgi.py)
file:
"""
WSGI config for django_project project.
It exposes the WSGI callable as a module-level variable named ``application``.
For more information on this file, see
https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
"""
import os
from dotenv import load_dotenv, find_dotenv
load_dotenv(dotenv_path=find_dotenv(filename='.env'))
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', f'settings.{os.getenv("DJANGO_SETTINGS_FILE")}')
application = get_wsgi_application()
a year ago
what's your start command
exec gunicorn --forwarded-allow-ips * django_project.wsgi:application --bind [::]:${BACKEND_DJANGO_PORT} --timeout 0
a year ago
and where are you defining that start command
a year ago
do you need to talk to your django app over the private network?
a year ago
use this then -
exec gunicorn django_project.wsgi --bind [::]:${PORT} --timeout 0 --forwarded-allow-ips *
side note, always best to use the standard names for environment variables such as PORT
, then since you will need a fixed port simply define PORT
as a service variable
Unfortunately I get the same error:
Failed to find attribute 'application' in 'Core'.
I must be doing something wrong:
gunicorn --forwarded-allow-ips * django_project.wsgi --bind [::]:${PORT} --timeout 0
a year ago
do you have the start command set elsewhere, like in the service settings?
Sorry, where would I find the service settings? I am not using a procfile or a gunicorn config file
a year ago
you can find the settings tab after opening your service
a year ago
share your dockerfile?
FROM python:3.11.6
WORKDIR /app/django_project
COPY ./backend-django/requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY ./backend-django /app
WORKDIR /app/django_project
EXPOSE 8000
EXPOSE 5672
EXPOSE 15672
# RUN python manage.py makemigrations && python manage.py migrate
CMD ["sh", "set_up.sh"]
And set_[up.sh](up.sh)
:
exec gunicorn --forwarded-allow-ips * django_project.wsgi --bind [::]:${PORT} --timeout 0
a year ago
no railway.json either?
a year ago
is django_project
the correct folder name?
a year ago
share your repo?
Here is my repository structure:
backend-django
django_project
AppTwo
...
Core
API
v1
__init__.py
admin.py
apps.py
helpers.py
permisssions.py
serializers.py
services.py
views.py
viewsets.py
v2
(similar to v1)
migrations
...
django_project
__init__.py
asgi.py
router.py
urls.py
wsgi.py
settings
__init__.py
base.py
settings_local.py
settings_production.py
set_up.sh
a year ago
quite hard to get a good grasp of what's going on like that, if sharing a link to your repo not a option, could you add me to it?
Unfortunately I had signed an NDA so it is not possible at the moment. But if you would like to look at a specific file I can do my best to provide it
a year ago
ah okay no worries
a year ago
I'm kinda out of ideas tbh
a year ago
you said running the same set_up.sh locally gives you the same error?
a year ago
are you running that script while in the same folder that the script resides in?
a year ago
back to having no ideas
Ah okay I fixed it. It was actually a syntax error where I did not put "*"
in:
exec gunicorn --forwarded-allow-ips * django_project.wsgi --bind [::]:${PORT} --timeout 0
a year ago
what a fun little bug
a year ago
it did give an example, yet i gave you the wrong start command, my bad
No problem! I am going to figure out why the Django application is not using the django_session
table