Access the session into sockets

[lud...@demblans.com]

Hi, 

Having fun with channels at the moment :)

I would like to know if it was a solution to access session variables into a Phoenix.Channel. I know that both websockets and XHR transport cookies, so it is physically possible ; but I'm not sure there is a way in Phoenix.

Thanks

[Chris McCord]

We don’t pass session information to the channel for a number of reasons, and instead favor token auth. Relying on the session is problematic because:

1. The Plug API breaks down after the connection is upgraded to a websocket (you can’t write to the session)

2. Channels are multiplexed, so if you join 10 channels on a single connection, you need to auth those topics anyway outside of the session (via tokens)

3. Channels are meant to be multiplatform, so your mobile client native apps likely won’t have a cookie session, and will need token auth.

We’re working to provide an API to make token generation and auth easier, but for now you need to pass up the data you require in `socket.join` on the client. 

If you just need to pass a few bits of data up, rendering on the layout and accessing via JS is an option:

    <script …

      var SocketExports = <%= %{foo: %{…}} |> JSON.encode! %>;

      …

      socket.join(“the:topic”, {foo: SocketExports.foo, …}, function(chan){ ...

    </script>

More elaborate data requirements could make an auth ajax request up or some JSON data and then that can be passed to `socket.join`

Our story should improve here soon. Hope that helps!

Chris

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at http://groups.google.com/group/phoenix-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/89eabd6f-3004-421d-966a-916e8542f58e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lud...@demblans.com]

Hi

Yes it helps and it makes sens. I love the fact that the long-polling fallback is faking a persistent connection (messages published in the moments where the polling request is not waiting) thanks to the channel. This gave me a hard time with Yaws

On more question please : I need private channels, i.e. only one user can access his/her own channel. For example, he joins("user:<user_id>") with a token, and the join/3 function in the channel checks if the provided token matches with the user_id of the topic. Isn't creating a channel per user overkill or is it the intended way to achieve this ?

Thank you