Cross origin request cookies - Django/Angular in separate containers

Using Django Deployment
1

Hi everyone.I am new to the domain of software engineering so I may not use the best terms to describe my situation! but i look forward to any advice or feedback anyone has.

I have started working on a pre-existing projject that has multiple docker containers.
Django is being used inside a container, and there is another container serving the front end (Angular/Apache).

I have had major grief in getting authentication and session cookies to be accepted by the browser in this setting which is cross origin I believe…

My HTTP requests are set to send to a URL (document.location.hostname), they are set to crossDomain and they are set to withCredentials.

My CORS headers whitelist the IP address (gets rid of one CORS error in the browser!)
CORS_ALLOW_CREDENTIALS = True
SESSION_COOKIE_SAMESITE = ‘None’
SESSION_COOKIE_SECURE = True

and then here i seem to get my probelms starting in that the cookies MUST be secure if samesite is None - so then my requests have to be HTTPS for the browser to attach a secure cookie to the request.
Django itself doesn’t do https/SSL stuff…

I am using django_extensions with runserver_plus as a workaround atm.

This app runs on a local network behind a lot of security and doesn’t “need” to be secure.

Is there away to modify Django Cors or cookie settings or my HTTP requests so that the cookies will without needing to be secure and needing HTTPS?
Can I somehow do a “cookie whitelist” to just the IP address of the frontend?

2

Keep in mind that this doesn’t matter regarding this issue. What CORS protects you against is one of your users visiting a different site that loads JavaScript in their browser that causes them to perform actions on your site.

You describe that you’re currently using Werkzeug (runserver_plus) as a “workaround”. How are you planning on running it as a “non-workaround”? (Please don’t say “runserver”. Really, don’t.)

You should already be using something like gunicorn or uWSGI - both of which support ssl. Or, in every deployment that we do, you run the Django app behind Apache. (Well, we don’t use Apache any more, we do everything behind nginx.) You allow Apache (or nginx) to handle the ssl and proxy the request to your gunicorn (or uwsgi) instance.

3

Hi. Thankyou for your reply! I feel if i say too much it will only make you depressed. Lets see if i can reply without saying - runserver?

I tried to do a bit of reading ‘around’ the topic before i posted so I have already come across what you mean. I even sent a screenshot of the part of the documentation that says not to use Django as a WSGI server in production and to use it with something else.

I raised putting it behind a WSGI server or a proxy and my team did not support this action currently.A member of my team indicated that django is used for this in many projects and that there must be a solution to the cross origin requests that does NOT involve HTTPS/SSL or needing to “add more” layers on top of it.

I really do appreciate your reply! It settles my mind a bit that what you said supports my research.

4

If you’re talking about using runserver as a production server, well, I won’t quite go so far as to say they know a lot of people who are making the same mistake. The reason I won’t say that is because I have a couple of projects running in very specific environments where runserver (actually, I use Werkzeug) is the appropriate solution.
However, I would never recommend it for general use. As you have found, the docs themselves recommend strongly against it.

Solution to the cross-origins policy? Sure - take it all out. This is all handled by configuration and middleware. Forget security and take your chances - that is an architectural decision that could be made. (I’m not sure I’d recommend it in the general case, but it is a choice.)

As a more serious response, ssl isn’t that big of a deal anymore. With services like LetsEncrypt making certs generally available for free, it doesn’t even cost anything. And with the general push toward “ssl everywhere”, it’s something you’ll want to address sooner rather than later.

5

Thankyou again for your input.
I guess my “problem” which isn’t really a porblem as its by design - is on the browser end more than the backend?
If i were to strip a lot out of django (which i won’t) -
would i end up in a situation where the browser will accept the “set-cookie” and attach the cookies to requests properly - in a cross origin context - without the secure tag (and therefore without SSL/HTTPS)?

6

I wouldn’t try to characterize this as either a “front end” or a “back end” issue - it spans both, and the need to secure both sides of the communication channel.

There’s not a lot to strip out - it’s one middleware package to remove. (Although, it’s still possible for third-party packages to force this to be used even without the middleware - but there are ways around that too.)

See How to use Django’s CSRF protection | Django documentation | Django and Cross Site Request Forgery protection | Django documentation | Django for more details about exactly what all this does.

1 Like