My project authenticates user session through channel and I would like to store session token that is created by channel on conn.assigns to authorize api access.
It seems possible to send data from controller to channel using broadcast, but I can’t find a way to send data from channel to controller.
Thanks for reading my question!
Hello and welcome,
Channels have no sessions, they use tokens for authentication, and controllers have no way to contact clients.
The flow would be easier if You use a controller to get session data, and maybe retrieve a token for socket connection authentication.
Anyway You could probably have the session token stored somewhere by user_id when channels have done their authentication task, and retrieve it when user contact controller.
Thanks for the reply.
My client receives token from channel and then send post request with the token to store current user and token in session for later use.
This seems redundant because the token is created on server and the client send it back to the server.
Is this inevitable if I authenticate user with channel?
I don’t see a clear way to share info between channels, to session, other than what You already do.
As mentionned, it is much easier to communicate from controllers to channels, because channels are always up.
But if it belongs to server side, I don’t see why it is send to client at first… other than You decided to authenticate via channels instead of controllers.
It is redundant but would be the way to approach this situation. A channel typically uses websockets (although transport agnostic) and websockets cannot set headers once the connection is established (because the connection switches protocols and no longer speaks http).
A typical flow for channel auth is for the http controller to own authentication, via cookies for example, and then include a signed token that passes information from server to client to WebSocket connection. You would use the signed token to access whatever data you included, such as the user id.
I will just keep the current approach for now