Closed samedii closed 7 months ago
sadness ...
when enabling SSL there are a bunch of caveat, some are documented in the doc. That page / https://machinezone.github.io/IXWebSocket/usage/#tls-support-and-configuration
Can you read and check it ? Ah and if you have existing GET/POST that part must be working ...
There is a known problem with some go backend, I can't remember. If I create a simple go/gorilla websocket program, I cannot connect to it either. The problem was with some missing header, but honestly I can't remember.
I would check if you can reproduce locally, by generating certificates and telling your starlette app to use them.
This is a library we tested against / https://websockets.readthedocs.io/en/stable/index.html
Also at some point we would be able to connect to a project running on AWS, but I can't tell if it was going through ALB or not.
Thanks for the quick response! :pray: I'll add https locally for testing and report back. It could be that Aseprite hasn't been compiled with the USE_TLS=1
flag. I'll try asking :)
I tested with agains this server -> wss://echo.websocket.org/
The first check is making your app can connect to this, send a dummy message and get something back.
build$ ./ws/ws connect wss://echo.websocket.org/
Type Ctrl-D to exit prompt...
Connecting to url: wss://echo.websocket.org/
[2024-02-23 21:33:14.858] [info] ws_connect: connected [2024-02-23 21:33:14.859] [info] Uri: / [2024-02-23 21:33:14.859] [info] Headers: [2024-02-23 21:33:14.859] [info] connection: Upgrade [2024-02-23 21:33:14.859] [info] date: Sat, 24 Feb 2024 05:33:14 GMT [2024-02-23 21:33:14.859] [info] fly-request-id: 01HQCSMWZPH5MQJ1Q0GK7JQMS5-sjc [2024-02-23 21:33:14.859] [info] sec-websocket-accept: pyUMTU5Oywk0joqEdUS1DQKoebA= [2024-02-23 21:33:14.859] [info] sec-websocket-extensions: [2024-02-23 21:33:14.859] [info] server: Fly/17d0263d (2024-02-15) [2024-02-23 21:33:14.859] [info] upgrade: websocket [2024-02-23 21:33:14.859] [info] via: 1.1 fly.io [2024-02-23 21:33:14.859] [info] Received 32 bytes ws_connect: received message: Request served by 1781505b56ee58 [2024-02-23 21:33:15.004] [info] Received pong ixwebsocket::heartbeat::30s::0 coucou [2024-02-23 21:33:42.038] [info] Received 6 bytes ws_connect: received message: coucou [2024-02-23 21:33:45.005] [info] Received pong ixwebsocket::heartbeat::30s::1
On Feb 23, 2024, at 2:51 AM, Richard Löwenström @.***> wrote:
Thanks for the quick response! 🙏 I'll add https locally for testing and report back. It could be that Aseprite hasn't been compiled with the USE_TLS=1 flag. I'll try asking :)
— Reply to this email directly, view it on GitHub https://github.com/machinezone/IXWebSocket/issues/501#issuecomment-1961109827, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2O6UPGQP6IUJHZCZCKVZDYVBYDNAVCNFSM6AAAAABDV2P6FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRGEYDSOBSG4. You are receiving this because you commented.
Thank you! :D I tested connecting to wss://echo.websocket.org/
and I'm getting the same error on handshake so it seems it hasn't been compiled with TLS/SSL support. I'll see if I can build "Aseprite" from source with the extra flag
Ah ah … good that’s progress.
On Feb 24, 2024, at 6:09 AM, Richard Löwenström @.***> wrote:
Thank you! :D I tested connecting to wss://echo.websocket.org/ and I'm getting the same error on handshake so it seems it hasn't been compiled with TLS/SSL support. I'll see if I can build Aseprite" from source with the extra flag
— Reply to this email directly, view it on GitHub https://github.com/machinezone/IXWebSocket/issues/501#issuecomment-1962384071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2O6UKH4ZO3O3FE3GW3JQDYVHYC3AVCNFSM6AAAAABDV2P6FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSGM4DIMBXGE. You are receiving this because you commented.
Managed to build Aseprite with SSL/TLS support. Thank you for the help! :pray:
Perfect !
On Feb 24, 2024, at 2:50 PM, Richard Löwenström @.***> wrote:
Closed #501 https://github.com/machinezone/IXWebSocket/issues/501 as completed.
— Reply to this email directly, view it on GitHub https://github.com/machinezone/IXWebSocket/issues/501#event-11911759569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2O6UKNKB7VRTDUIMUI5GLYVJVDJAVCNFSM6AAAAABDV2P6FSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRHEYTCNZVHE2TMOI. You are receiving this because you commented.
We have been forced to use websockets without SSL for a while but this is surprisingly hard to solve. We are using a very standard setup with FastAPI + starlette websockets behind ALB with native support for websockets.
This is the application that we are building around that is using your library: https://github.com/aseprite/aseprite/blob/main/src/app/script/websocket_class.cpp
Do you think this could be related to client behaviour? It feels like AWS ALB should be very battle tested.
It seems like it gets stuck in the ALB and never gets to our backend. Note that we also have GET/POST HTTPS endpoints on the same server that work without any issues so the setup seems fine.
This is likely related but felt lacking in information: https://github.com/machinezone/IXWebSocket/issues/425
Any advice on where to dig would be greatly appreciated! :pray: