[cyberpunk]

I am a fan of the idea, but the websocket is also quite a big attack surface; you can do a lot more by sending messages over this socket to your phoenix app than you would likely expect to have exposed via some api on another framework.

It’s difficult to secure, in my opinion. Perhaps not impossible but the cost of doing so pretty much eclipses the benefits of using liveview imo.

[ch4s3]

You authenticate and authorize them the same way you do any other frontend requests. The socket gets an authenticated user and you handle messages in that scope. It’s not hard at all. Since messages have a shape that has to structurally match you can’t just dump arbitrary messages on the socket and get replies.

[mcintyre1994]

I haven’t used it for anything in production so I haven’t seen these issues, could you give a bit more detail? I’m mostly wondering why you’d have any more websocket messages that you respond to than you would APIs if you were using any other approach. Does LiveView itself respond to certain messages bypassing your app?

[GCUMstlyHarmls]

There is some propensity to forget that you're basically making a REST API because its all "in my process, responding to messages", it feels like you're writing your regular server side render controller. But really instead of `PUT /create/post` its `websocket.send("create_post", {})`, so you need to understand that if you only want to operate on `user_id=1`, you need to not just accept `{user_id: 1, ...data}`.

I dont think its inherently any more insecure than another method, you just have to recognize that clients can create malicious requests to `handle_event(my_event, params, socket)`, just like you might to `my_action(params, conn)`. It's also pretty painless, normal, to just crash on bad data, it will only effect that one naughty lv process.

You could also send "control" signals to the phoenix liveview process via the same socket but I dont think that actually as much surface outside of heartbeats and closing the socket.

[kitd]

Why? It's the client that initiates the connection.