socketio.run() - provide a way to force a production server

[ThiefMaster]

If eventlet or gevent are available, socketio.run(app) starts a production-ready server using one of these frameworks. If neither of these are installed, then the Flask development web server is used, and in this case the server is not intended to be used in a production deployment.

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...

[miguelgrinberg]

The standard warning used by the Flask dev server appears when you run socketio.run() in production, and the chosen server is Werkzeug. This is the same protection mechanism used in Flask.

(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)

[ThiefMaster]

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.

[miguelgrinberg]

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.

With the normal flask app.run() on the other hand it's known that its never suitable for production.

Yet, I see tons of Dockerfiles out there that have flask run or python app.py as entry points.

I guess the correct thing to do would be to prevent socketio.run() from starting Werkzeug in production mode, unless you explicitly enable it with an option. I'll think about that.

[miguelgrinberg]

@ThiefMaster @davidism I've changed the socketio.run() function to raise an error when Werkzeug is being used, and there is no stdin (meaning that the application is likely running under docker or other platform, as opposite to running it directly on a terminal). Would you review and let me know if this addresses your concerns? Thanks!

[davidism]

This is a clever idea, I wonder if I should apply it to the development server in general.

[alethiophile]

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.

[miguelgrinberg]

@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.