-
-
Notifications
You must be signed in to change notification settings - Fork 890
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
socketio.run() - provide a way to force a production server #1814
Comments
The standard warning used by the Flask dev server appears when you run (venv) example $ python app.py *main
* Serving Flask app 'app' (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000 (Press CTRL+C to quit) |
Sure, but if you deploy e.g. using Docker+k8s you very are unlikely to look at the output. So if something gets messed up with the deps you install, you end up with the dev server without noticing.. With the normal flask app.run() on the other hand it's known that its never suitable for production. |
Yes, I understand the concern, but adding an obscure kwarg to the docs (that nobody will ever see) isn't an effective way to prevent inadvertent uses of Werkzeug. The developer who reads the documentation and learns about these flags is actually not the one that is going to make a mistake with this.
Yet, I see tons of Dockerfiles out there that have I guess the correct thing to do would be to prevent |
@ThiefMaster @davidism I've changed the |
This is a clever idea, I wonder if I should apply it to the development server in general. |
This change is annoying, because I use Docker for development as well as for production, and now I have to put in a useless keyword argument every time I run it. Is there some better way to determine development vs. production status than just "running in Docker"? Hell, Docker was originally meant to be a development environment, not a production deployment system. This basis of determination seems flawed. |
@alethiophile The idea is to prevent people from mistakenly running dev mode when they think they are running production. We can debate whether Docker was designed for development use or not, but that is irrelevant, since the fact is that there is a significant amount of people who use it on production, where a configuration mistake can result in exposure to attacks. This feature is designed to prevent that, even if it adds a bit of an inconvenience for some people. If you want to propose an alternative solution that ensures production users remain protected please do so. |
This means that you could end up in a situation where you think you get a production-ready server but don't because there's something wrong with your dependencies. Maybe a kwarg to run() that causes it to fail if there's no production-grade server available would be a good idea...
Of course one can just use one of the other deployment options such as running it via gunicorn etc., but if
run()
claims to be fine for production, having this fallback is a bit risky...The text was updated successfully, but these errors were encountered: