Cookiecutter-django: django-extensions on production?
The django-extensions package is currently only available locally. It's obviously a bad idea to run runserver_plus on production, but e.g. the shell management command is pretty neat.
Any other reasons why this is restricted to the development environment?
jayfk
All 2 comments
It's extremely intentional on my part to limit django-extensions to non-production environments. Why? Well, IMO django-extensions is full of security concerns. The biggie is runserver_plus, which runs werkzueg, which was the gateway used in the Patreon hack. In theory, that shouldn't have happened, but as shown from the Patreon incident, accidents do happen. That's the incident we know about, but I would be very surprised if it hasn't happened several or many times in the past to Django and Flask powered projects.
That feature of django-extensions has always scared me, hence the exclusion of that package from our production environment.
Heck, I don't even like django-extensions. Why not? Well - it does too much:
- runserver_plus
- shell_plus
- graphing of models
- model extensions
- sqldiff
- template stuff
- much, much more!
The volume of things it does isn't a feature IMO, it's a flaw. Furthermore, it incapsulates all that stuff in sophisticated... cough... spaghetti code. When code gets that sophisticated for no good reason, what other security holes can/does it open?
Periodically I look for something like shell_plus outside of django-extensions. Alas, no luck so far, which I'm 100% certain is because the package is so 'sophisticated' it is hard to extract code from.
So let me finish this diatribe by saying that if there exists a port of shell_plus from django-extensions to an independent/focused package, I would love to include it in cookiecutter-django.
pydanny
on 20 Nov 2015
Periodically I look for something like shell_plus outside of django-extensions. Alas, no luck so far, which I'm 100% certain is because the package is so 'sophisticated' it is hard to extract code from.
It would be nice if this was still maintained:
django-shell-plus 1.1.7
As it is, it relies on the deprecated NoArgsCommand from 'django.core.management.base
johnmathews
on 29 Jun 2020
Related issues
sebastian-code
路
4Comments
saschalalala
路
4Comments
linuxluigi
路
3Comments
jsmedmar
路
3Comments
StupidTAO
路
3Comments
Most helpful comment
It's extremely intentional on my part to limit django-extensions to non-production environments. Why? Well, IMO django-extensions is full of security concerns. The biggie is
runserver_plus, which runswerkzueg, which was the gateway used in the Patreon hack. In theory, that shouldn't have happened, but as shown from the Patreon incident, accidents do happen. That's the incident we know about, but I would be very surprised if it hasn't happened several or many times in the past to Django and Flask powered projects.That feature of django-extensions has always scared me, hence the exclusion of that package from our production environment.
Heck, I don't even like django-extensions. Why not? Well - it does too much:
The volume of things it does isn't a feature IMO, it's a flaw. Furthermore, it incapsulates all that stuff in sophisticated... cough... spaghetti code. When code gets that sophisticated for no good reason, what other security holes can/does it open?
Periodically I look for something like
shell_plusoutside of django-extensions. Alas, no luck so far, which I'm 100% certain is because the package is so 'sophisticated' it is hard to extract code from.So let me finish this diatribe by saying that if there exists a port of
shell_plusfrom django-extensions to an independent/focused package, I would love to include it in cookiecutter-django.