search

miguelgrinberg / turbo-flask

Integration of Hotwire's Turbo library with Flask.
MIT License
301 stars 35 forks source link

Turbo Stream 500 (Connection error) #45

Open smeetsomaiya opened 1 year ago

smeetsomaiya commented 1 year ago

This issue pops up every now and then. I am unable to figure out what causes it

Screen Shot 2022-12-12 at 1 22 07 AM
simon-bueler commented 1 year ago

I got the same issue. It launches a GET to /turbo-stream without calling the actual site I implemented a stream on. Any update on this issue, or any way I can help with fixing this? Issue is present on v0.8.3 but not on v0.8.2

miguelgrinberg commented 1 year ago

@simon-bueler what version of Werkzeug do you have? You may want to try upgrading Flask and Werkzeug to latest (if you can), as I believe this is only a problem with older releases.

In any case, this issue occurs due to being very difficult to get Werkzeug to handle a WebSocket route. Since you will be using this web server only for development this isn't a major problem. Once you switch to Gunicorn for your production release this isn't going to happen anymore.

simon-bueler commented 1 year ago

@miguelgrinberg I use: Flask>=2 werkzeug>=2

which results in Flask 2.2.2 werkzeug 2.2.2

miguelgrinberg commented 1 year ago

@simon-bueler Well, as I said, Werkzeug has been very difficult to tame wrt having a WebSocket route. I may have another look at some point, but given that this is a development web server I do not consider it the highest priority. The error occurs when the WebSocket connection is closed, so you can still use Werkzeug during development and it should work just fine with the exception of this error when a client goes away.

Also, just to clarify, the version of this package doesn't really matter much. The problem occurs between Flask-Sock and Werkzeug.

simon-bueler commented 1 year ago

@miguelgrinberg I tried gunicorn to run my app and as you said I did not encounter the issue there. On the other hand it was extremely slow in comparison and ran into multiple WORKER TIMEOUT issues and my turbo stream didn't run at all. So not sure if this is due to my use of msal but I will see what I can do. Just leaving this here if someone facing similar issues.

simon-bueler commented 1 year ago

Found a suitable solution for my case. Issue was, that the login procedure of msal somehow generates a call to /turbo-stream which resulted in a ssl.SSLEOFError: EOF occurred in violation of protocol which caused a ERROR:app:process_auth_redirect: security violation () for the login. Since the site where the stream should run is only available when loged in, I added a block to the main template for the {{ turbo() }} part and only load it on that site.