Add helpers for sockets about bodyguard

[schrockwell]

Something to think about: topics in socket handlers are strings, but controller actions are atoms. Pattern matching these types of actions won't work out of the box. We can't blindly convert strings to atoms, because atoms are not garbage collected in the Erlang VM.

[bencates]

Plus those strings usually have some formatting in them. Is there a generalized way to assume that the room "post:123" maps to authorize? current_user(socket), :show, Repo.get(Post, 123)?

[schrockwell]

I would say, in general, no. I don't think that's a convention we would want to enforce.

There are three distinct aspects of sockets that need authorizing: (1) socket connect, (2) channel join, and (3) channel messages in AND out (you can handle_out to filter outgoing messages)

I'm not sure we need to worry about (1). Is there a case where we would want to explicitly deny a user connection to the socket server altogether, even before they've attempted to join any channels (i.e. perform any destructive actions)?

(2) and (3) are similar enough (and implemented in the same modules) that I think they can be lumped together. I've already found myself calling the scope functions directly on my policies, so I think a scope helper would be useful. We can assume socket.assigns.current_user exists, like we do for conn, and make that :current_user key configurable at the app level. The same goes for authorize!, and I think we will just have to require the user to explicitly pass in the action atom instead of trying to determine it automatically.

I'm undecided if we want to go the exception-raising route for channels. For join we can return {:error, %{reason: "unauthorized"}} which is clean and idiomatic. For handle_in we will want to return either {:noreply, socket} or {:stop, :unauthorized, socket}, the latter of which will kill the channel process. Or we could just raise, which will also kill the channel.

[schrockwell]

Or we could assume that once a user joins a channel, they are completely authorized, and all channel messages are therefore authorized and valid, so we don't even handle case (3) at all.

That certainly works for some cases (e.g. once you join a chat room, you are authorized to push messages to it, request chat history, request the chatroom members, etc.), but it's probably not general enough of an approach.

[schrockwell]

This will be fixed in v2.0 by just using the assigns of whatever actor we're given, whether it's a Plug.Conn, or a Phoenix.Socket, or anything else.