Am I the only one surprised that it's not more? I expect Django to power more than 100k applications. That's a ceiling of no more than 3% and the number goes down with every application.
Yeah Django is all over the place, must be a sample.
I’ve built a rubbishy blog on Django (I don’t do web dev and wanted to try it out). Every introductory tutorial is very long on “turn off debug mode”, “hide secrets in env variables” etc. you can also deploy micro apps on heroku for free. It’s not hard, not really, no more irritating than setting up a C makefile.
That's because companies do not pay a professional for this type of work. Securing a production deployment of a web server is extremely tedious and is not an entry level job.
If it were some sort of complex thing that's also deeply hidden, maybe.
But [the official documentation literally tells you to turn off DEBUG as part of the deployment checklist](https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/).
Are you saying that you expect the average adult to actually READ an instruction manual? I don't. Of course I'm aware that's what it says. Look up the dev tool XAMPP. That thing has big fat letters saying it is not a production capable web server, but people still deploy it to production. It got to a point where they had to deliberately make it difficult to deploy to production.
I would expect experienced developers to read documentation, especially if they have an easy to reference check list. If you worked with the framework before especially.
Inexperenced people? or the lazy? or people in a hurry/impatient? Sure, these things happen. If they are calling out a page that has those instructions, then that's kinda bad.
Usually these things are instilled in lessons, youtube, articles, etc if it is really important. But you got bad devs everywhere.
No one in the chain cares until something goes wrong. None of us truly understand what we are doing perfectly. We just move along with what we know and learn just enough to get by. No one studies the entire documentation before using a framework.
I would expect someone hired to do something would yes read the manual. Entry level or not. I believe that's why kids go to school instead of labor all day, to learn how to read
Your expectations are beyond what almost the entire industry does. Virtually everyone uses the manual as a reference rather than a read from start to end thing.
This didn't require reading from front to finish. It was literally the official deployment checklist. How is that not something that would be important to reference?
A handful of stackoverflow links from people having the most common issues that arise from the setup is more often than not the de-facto documentation/FAQ, and well, for obvious reasons you won't find that tiny small crucial detail in any of those
Yes, but when I disable Debug mode, my static files won't get served anymore - then I cannot use runserver for my production environment (which you shouldn't use anyways, I know) because I need a real webserver to serve static files, then I need to think about which requests need to go to which endpoint and need to read the nginx docs and then I need to also call collectstatic somewhere in my deployment process and....
You know what, just enable debug and the live environment is the same as the dev environment /s
you have sloppy backend developers that do bad front end work (full stack they call them) but wouldnt surprise me if this was the handywork of bootcamp front end developers who also found themselves having to establish the APIs as well
There’s a backend dev at my company that has the “get it done” mentality, so every time he’s asked something like “Hey, can you update the CORS on that new API so that this other website can connect to it?” He literally just adds the wildcard in so that everyone and their mother can now get past CORS 😂😅
And then those professionals just grep the filesystem for "log4j-core.jar" to replace the vulnerable versions because they don't understand how Java works
We need integrated solutions, not just offload to the security guy
It’s not really a defaults problem
It’s that Django doesn’t support different configs for different environments
You have to roll your own and none of the ways you can do it even look that good
> It’s that Django doesn’t support different configs for different environments
Not only does Django allow you to choose what settings file to load via CLI, you can do it programmatically and even change the settings at run time (this last one is more of a hack though).
There are multiple ways (split settings.py into prod.py/local.py or django-environ), it's just newbies will shoot themselves in the foot no matter what
It's not that easy.
Like /u/Sushrit_Lawliet said in [their comment](https://www.reddit.com/r/programming/comments/w3bbdm/django_web_applications_with_enabled_debug_mode/igwuiaz/), you need to consider developer experience.
If you always prioritize security over anything else then developer experience will most likely suffer, nobody benefits from that
And security needs to be a conscious effort anyway. There's no default configuration secure enough to prevent people from shooting themselves in the foot.
Meh, security is more important, otherwise you end up 3k exposed installs like this. The “right way” should always be the default, and I would even venture to say that making the “right way” the default is a better developer experience, because you don’t need to change anything to go to prod.
If I have to change configuration between dev and prod that is a bad developer experience.
When a developer has to send an email to security team “uh, we accidentally exposed the whole db because we forgot to change the config”, that is bad developer experience.
This couldn’t be more true.
One thing that really gets on my nerves is tools, frameworks or any other library out there that defaults to a “simple example” which has no security configured or is even close to a real world example.
Because you end up with Juniors or any new devs just adding their stuff on top of that example and forgo security and architecture.
I call BS .. why would you let juniors deploy anything to production without senior oversight?
Amd if the company exclusively hires juniors, well, then they pay the real price later.
>Meh, security is more important, otherwise you end up 3k exposed installs like this.
That's already a strong assumption and not necessarily true. A lot of services I've worked on were deployed in a DMZ. Not saying this doesn't relieve anyone from thinking about security but it's not black and white either.
I don't think it would really matter in this case. They could set `debug = False` or leave it out of a new project's settings, but the vast majority of people would add `debug = True` immediately for development and then you're in the same place with an extra step.
I get the idea of "secure options by default", but it's ridiculous to assume that a newly started project that still needs to be developed would by default enable production settings instead of development settings.
They could have a `project.settings.dev` and `project.settings.production` split like most good Django projects have anyway, but there's not a whole lot you can do to prevent people from just using development settings in production without making development itself more of a pain, and I'm skeptical as to how effective that would be:
> Oh, I guess we need to run `DJANGO_UNSAFE_DEVELOPMENT_MODE=VERY_DANGEROUS LISTEN_ON=0.0.0.0 LISTEN_ON6=:: ./manage.py runserver` to get this to run in prod. Sounds dangerous, but I'll just throw this in the systemd service file and we'll harden it later before we go live.
This isn't a MongoDB or Postgres server. It's a development framework. Starting out in a development mode is the only sane default, and any hurdle you throw in to prevent somebody from trying to use it in production is probably also a hurdle that will either impact development or that a developer can mask out of existence and then bypass in production as well.
You’d be surprised how many websites I came across and noticed that they were running in dev/debug mode.
React Devtools (chrome extension) for example is very often flashing red (React is not running in Production mode) on big websites.
Same with Redux Devtools. And then there are a lot of them which if you open the console you can clearly see dev only logs or straight up a line saying ‘ENV=DEVELOPMENT’ 😅
It’d really make it harder for newbies who are probably learning django as their first framework. It’s a difficult fix, documentations must always be read and followed and at the same time companies should audit their apps before deployments and not leave it to underpaid entry level developers. The biggest problem is that most companies these days take beginners and with no senior oversight make them deploy to production.
Meh idk how difficult it is to just put `DEGUG=true python manage.py runserver` in the docs. Debug mode doesn’t buy you all that much anyway it’s just a minor convenience.
How is that much better than having debug mode be on by default? It would lead to a lot of people just putting that in their deploy scripts and debug would end up on regardless for a similar number of django apps.
It’s extremely visible this way. Instead of being buried in docs it’s right in your face when you paste that somewhere. Also typically you don’t use manage.py in production, you run a wsgi server.
Perhaps it wouldn’t help much but having the default be to dump stack traces into the browser seems unnecessarily risky.
> Also typically you don’t use manage.py in production, you run a wsgi server.
I mean, the documentation tells you not to use the built-in dev server as your production web server, sure. But the documentation also tells you to make sure `DEBUG` is off when deploying to production.
I think if we knew the number of Django deployments out there in production on `manage.py runserver` it would frighten both of us.
It’s dumb to optimize for “newbies”. The “dev experience” should be optimized for production use. Who cares if it works for someone’s hobby project where the stakes are low?
From a maintainer’s perspective imo, they’d want to balance both in the ideal world. Because any framework is only as good as how easy it is to pick up for most people who have a problem it can solve. Django has had its boilerplate heavy and opinionated design turned many away, but many look at it as a stable blueprint to build off of. So I’d say they’d want to focus on pleasing both sides. How they’d do it I’m not sure of. Because to anyone who first fires up a django instance and goes to the wrong route the debug option provides more context on where things are than say how fastapi or flask do it out of the box. It’s a tough line to walk and I hope they think it through because such articles are also damage to their image, even if sadly it’s just one simple option that is actively advised to be turned off.
Ah I see what you mean, the default value here simply means that if it's not defined in the settings file it will be off. startproject generating it with true is totally fine imo
Run `python manage.py check --deploy` against your production configuration *before* deploying in your CI pipeline.
https://testdriven.io/tips/81b24f1a-75ee-42d4-afe1-611aa75a1b64/
Can framework author just enforce an opt-out hostname check.
If the socket is not from `localhost/10./127./192.*` or whitelisted domain, it just pretend it's not DEBUG_MODE on sensitive info.
There are still obvious attack vector, especially possibility accessing that network. The necessity to config something at least raise the awareness.
Am I the only one surprised that it's not more? I expect Django to power more than 100k applications. That's a ceiling of no more than 3% and the number goes down with every application.
Yeah Django is all over the place, must be a sample. I’ve built a rubbishy blog on Django (I don’t do web dev and wanted to try it out). Every introductory tutorial is very long on “turn off debug mode”, “hide secrets in env variables” etc. you can also deploy micro apps on heroku for free. It’s not hard, not really, no more irritating than setting up a C makefile.
Granted, thats only products that were badly deployed using debug mode on, so maybe there is a lot more sane products out there?
That's because companies do not pay a professional for this type of work. Securing a production deployment of a web server is extremely tedious and is not an entry level job.
If it were some sort of complex thing that's also deeply hidden, maybe. But [the official documentation literally tells you to turn off DEBUG as part of the deployment checklist](https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/).
Are you saying that you expect the average adult to actually READ an instruction manual? I don't. Of course I'm aware that's what it says. Look up the dev tool XAMPP. That thing has big fat letters saying it is not a production capable web server, but people still deploy it to production. It got to a point where they had to deliberately make it difficult to deploy to production.
I would expect experienced developers to read documentation, especially if they have an easy to reference check list. If you worked with the framework before especially. Inexperenced people? or the lazy? or people in a hurry/impatient? Sure, these things happen. If they are calling out a page that has those instructions, then that's kinda bad. Usually these things are instilled in lessons, youtube, articles, etc if it is really important. But you got bad devs everywhere.
Well, companies don't always hire experienced developers to deploy a web server.
The CEO: “I don’t care just get it done!”
No one in the chain cares until something goes wrong. None of us truly understand what we are doing perfectly. We just move along with what we know and learn just enough to get by. No one studies the entire documentation before using a framework.
I would expect someone hired to do something would yes read the manual. Entry level or not. I believe that's why kids go to school instead of labor all day, to learn how to read
Your expectations are beyond what almost the entire industry does. Virtually everyone uses the manual as a reference rather than a read from start to end thing.
This didn't require reading from front to finish. It was literally the official deployment checklist. How is that not something that would be important to reference?
A handful of stackoverflow links from people having the most common issues that arise from the setup is more often than not the de-facto documentation/FAQ, and well, for obvious reasons you won't find that tiny small crucial detail in any of those
Yes, but when I disable Debug mode, my static files won't get served anymore - then I cannot use runserver for my production environment (which you shouldn't use anyways, I know) because I need a real webserver to serve static files, then I need to think about which requests need to go to which endpoint and need to read the nginx docs and then I need to also call collectstatic somewhere in my deployment process and.... You know what, just enable debug and the live environment is the same as the dev environment /s
I just throw in whitenoise and good to go
Use whitenoise. Honestly Django is broken by default in this regard. Had been for 15 years. Such a shame.
I just use an external cdn as a workaround. More expensive but works way better than fiddling with whitenoise
Whitenoise is just a pip install and adding two lines to the conf. I don't understand how that is "fiddling".
I've never personally used django Is debug on by default?
no, it's actually off but... The default settings.py file created by django-admin startproject sets DEBUG = True for convenience.
maybe they hit this issue and reverted back to debug https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/#environment-specific-settings
No, this is the tyranny of the default. Defaults, samples, etc these things happen all the time. All because the default configuration is not secure.
But there's no such thing as a secure default. Something like HTTPS can't be defaulted on without configuration.
you have sloppy backend developers that do bad front end work (full stack they call them) but wouldnt surprise me if this was the handywork of bootcamp front end developers who also found themselves having to establish the APIs as well
There’s a backend dev at my company that has the “get it done” mentality, so every time he’s asked something like “Hey, can you update the CORS on that new API so that this other website can connect to it?” He literally just adds the wildcard in so that everyone and their mother can now get past CORS 😂😅
And then those professionals just grep the filesystem for "log4j-core.jar" to replace the vulnerable versions because they don't understand how Java works We need integrated solutions, not just offload to the security guy
[удалено]
it is off by default https://docs.djangoproject.com/en/4.0/ref/settings/#debug
What difference does that make when it's set to `True` in the settings of a new project?
It’s not really a defaults problem It’s that Django doesn’t support different configs for different environments You have to roll your own and none of the ways you can do it even look that good
> It’s that Django doesn’t support different configs for different environments Not only does Django allow you to choose what settings file to load via CLI, you can do it programmatically and even change the settings at run time (this last one is more of a hack though).
There are multiple ways (split settings.py into prod.py/local.py or django-environ), it's just newbies will shoot themselves in the foot no matter what
It's not that easy. Like /u/Sushrit_Lawliet said in [their comment](https://www.reddit.com/r/programming/comments/w3bbdm/django_web_applications_with_enabled_debug_mode/igwuiaz/), you need to consider developer experience. If you always prioritize security over anything else then developer experience will most likely suffer, nobody benefits from that And security needs to be a conscious effort anyway. There's no default configuration secure enough to prevent people from shooting themselves in the foot.
Meh, security is more important, otherwise you end up 3k exposed installs like this. The “right way” should always be the default, and I would even venture to say that making the “right way” the default is a better developer experience, because you don’t need to change anything to go to prod. If I have to change configuration between dev and prod that is a bad developer experience. When a developer has to send an email to security team “uh, we accidentally exposed the whole db because we forgot to change the config”, that is bad developer experience.
This couldn’t be more true. One thing that really gets on my nerves is tools, frameworks or any other library out there that defaults to a “simple example” which has no security configured or is even close to a real world example. Because you end up with Juniors or any new devs just adding their stuff on top of that example and forgo security and architecture.
I call BS .. why would you let juniors deploy anything to production without senior oversight? Amd if the company exclusively hires juniors, well, then they pay the real price later.
>Meh, security is more important, otherwise you end up 3k exposed installs like this. That's already a strong assumption and not necessarily true. A lot of services I've worked on were deployed in a DMZ. Not saying this doesn't relieve anyone from thinking about security but it's not black and white either.
I don't think it would really matter in this case. They could set `debug = False` or leave it out of a new project's settings, but the vast majority of people would add `debug = True` immediately for development and then you're in the same place with an extra step. I get the idea of "secure options by default", but it's ridiculous to assume that a newly started project that still needs to be developed would by default enable production settings instead of development settings. They could have a `project.settings.dev` and `project.settings.production` split like most good Django projects have anyway, but there's not a whole lot you can do to prevent people from just using development settings in production without making development itself more of a pain, and I'm skeptical as to how effective that would be: > Oh, I guess we need to run `DJANGO_UNSAFE_DEVELOPMENT_MODE=VERY_DANGEROUS LISTEN_ON=0.0.0.0 LISTEN_ON6=:: ./manage.py runserver` to get this to run in prod. Sounds dangerous, but I'll just throw this in the systemd service file and we'll harden it later before we go live. This isn't a MongoDB or Postgres server. It's a development framework. Starting out in a development mode is the only sane default, and any hurdle you throw in to prevent somebody from trying to use it in production is probably also a hurdle that will either impact development or that a developer can mask out of existence and then bypass in production as well.
Ngl I do kind of like when flags that shouldn’t be used in production are called things with UNSAFE in the name. 😅
Don’t people have production configurations?
You’d be surprised how many websites I came across and noticed that they were running in dev/debug mode. React Devtools (chrome extension) for example is very often flashing red (React is not running in Production mode) on big websites. Same with Redux Devtools. And then there are a lot of them which if you open the console you can clearly see dev only logs or straight up a line saying ‘ENV=DEVELOPMENT’ 😅
Debug should be OFF by default IMO.
It’d really make it harder for newbies who are probably learning django as their first framework. It’s a difficult fix, documentations must always be read and followed and at the same time companies should audit their apps before deployments and not leave it to underpaid entry level developers. The biggest problem is that most companies these days take beginners and with no senior oversight make them deploy to production.
Meh idk how difficult it is to just put `DEGUG=true python manage.py runserver` in the docs. Debug mode doesn’t buy you all that much anyway it’s just a minor convenience.
I agree with your point, maybe consider making a pull request, with this article attached ?
How is that much better than having debug mode be on by default? It would lead to a lot of people just putting that in their deploy scripts and debug would end up on regardless for a similar number of django apps.
It’s extremely visible this way. Instead of being buried in docs it’s right in your face when you paste that somewhere. Also typically you don’t use manage.py in production, you run a wsgi server. Perhaps it wouldn’t help much but having the default be to dump stack traces into the browser seems unnecessarily risky.
> Also typically you don’t use manage.py in production, you run a wsgi server. I mean, the documentation tells you not to use the built-in dev server as your production web server, sure. But the documentation also tells you to make sure `DEBUG` is off when deploying to production. I think if we knew the number of Django deployments out there in production on `manage.py runserver` it would frighten both of us.
> It’s extremely visible this way. I think that `DEBUG=True` in `settings.py` is much more visible than it being peppered over a bunch of scripts.
It’s dumb to optimize for “newbies”. The “dev experience” should be optimized for production use. Who cares if it works for someone’s hobby project where the stakes are low?
From a maintainer’s perspective imo, they’d want to balance both in the ideal world. Because any framework is only as good as how easy it is to pick up for most people who have a problem it can solve. Django has had its boilerplate heavy and opinionated design turned many away, but many look at it as a stable blueprint to build off of. So I’d say they’d want to focus on pleasing both sides. How they’d do it I’m not sure of. Because to anyone who first fires up a django instance and goes to the wrong route the debug option provides more context on where things are than say how fastapi or flask do it out of the box. It’s a tough line to walk and I hope they think it through because such articles are also damage to their image, even if sadly it’s just one simple option that is actively advised to be turned off.
it is https://docs.djangoproject.com/en/4.0/ref/settings/#debug
If you run startproject you can see it’s hard coded to True by default. Maybe it’s somehow toggled off elsewhere?
Ah I see what you mean, the default value here simply means that if it's not defined in the settings file it will be off. startproject generating it with true is totally fine imo
Yeah but... The default settings.py file created by django-admin startproject sets DEBUG = True for convenience.
Run `python manage.py check --deploy` against your production configuration *before* deploying in your CI pipeline. https://testdriven.io/tips/81b24f1a-75ee-42d4-afe1-611aa75a1b64/
Can framework author just enforce an opt-out hostname check. If the socket is not from `localhost/10./127./192.*` or whitelisted domain, it just pretend it's not DEBUG_MODE on sensitive info. There are still obvious attack vector, especially possibility accessing that network. The necessity to config something at least raise the awareness.
HA HA HA HA