How to access http headers in Phoenix socket?

Phoenix Forum Questions / Help
,
1

Can not get http header info from a Phoenix socket.

%Phoenix.Socket{
  assigns: %{},
  channel: nil,
  channel_pid: nil,
  endpoint: Web.Endpoint,
  handler: Web.UserSocket,
  id: nil,
  join_ref: nil,
  joined: false,
  private: %{},
  pubsub_server: App.PubSub,
  ref: nil,
  serializer: Phoenix.Socket.V2.JSONSerializer,
  topic: nil,
  transport: :websocket,
  transport_pid: nil
}
2 Likes
2

:wave:

There is also connect_info passed as an optional third argument to connect/3 callback, it might be worth checking for headers there.

  def connect(params, socket, _connect_info) do
    {:ok, assign(socket, :user_id, params["user_id"])}
  end
5 Likes
3

Also don’t forget to actually enable sending those headers by configuring your socket on your Endpoint correctly as described here: https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#socket/3-common-configuration

So your Endpoint socket declaration should look like something like this:

# inside the file lib/my_app_web/endpoint.ex
#
socket "/socket", MyAppWeb.UserSocket,
  websocket: [
    connect_info: [:peer_data, :x_headers, :uri]
  ]

Now you should see those headers being forwarded inside the connect_info key during the connect callback as idiot described above.

9 Likes
4

Thank you two, I got it. :smile:

5

This seems to only give access to headers that start by X_SOME_HEADER, but not to headers like SOME_HEADER:

CONNECT INFO: %{
  peer_data: %{
    address: {0, 0, 0, 0, 0, 65535, 44054, 5},
    port: 48096,
    ssl_cert: nil
  },
  trace_context_headers: [],
  uri: %URI{
  ....
  },
  x_headers: [
    {"x-forwarded-host", "example.com"},
    {"x-forwarded-port", "443"},
    {"x-forwarded-proto", "https"},
    {"x-forwarded-server", "e4df7cbb6ae1"},
    {"x-real-ip", "xxx"}
  ]
}

So, is there a way to get all the normal headers we get from conn.req_headers?

6

There is not. The available options are listed here:

7

If you really wanted I think you could selectively rewrite/duplicate the headers you want to x_some_header format so you can access them via x_headers. Could be possible via a plug that’s running before the socket endpoint, otherwise it should be possible with a Cowboy handler, last resort that should always work is doing the rewrite from something that’s in front of your app like Nginx or Haproxy? But it’s not that trivial to do.

Are you able to share you existing use case? Just curious and maybe there’s another solution for it.

1 Like
8

I am writing an Elixir Quickstart for a Thrird Party integration in any Elixir API serving mobile apps, and I need to check that the Third Party JWT token is valid in the request that establishes the socket connection.

I have a Plug that checks it for the regular HTTP requests, and I though that I could use it to check the token in the http request to upgrade to a socket but I am not seeing how to do it, therefore I am trying to find if I can do it in the socket itself, but it seems that is also not possible.

Rewriting them in a plug or using a Cowboy handler looks like an hack and not developer friendly in a Third Party integration, but if I am left without any other alternative I may have to go for it.

That’s not a desirable option for a Third Party integration.

I am now reading the core code of the Phoenix Framework in the hope I can find a path, but I am about to conclude that is not possible :frowning:

So, if you have any other ideas I am more then happy to try them out.

9

I have an API product in production that authenticates JWT tokens on the phoenix socket ‘connect’. But the token comes in through query params, you can’t use that way also?

10

There’s a reason for the options to be as restricted as they are: Phoenix channels are meant to be transport agnostic. The more implementation details surface into the actual channels system the more it becomes impossible to switch out transports transparently. So details are kept intentionally limited. In your case it might make sense to write a custom transport, which has access to the complete conn for websocket based connections and it can then – similar to phoenixs implementation – surface transport specific data to the user socket including your token data.

1 Like
11

Thinking about it, what you could also try if you still want to use the JWT token from the header, is to make a HTTP route that you land on as a user, authenticates the JWT and redirects to the socket path but this time with a phoenix token inside the query params. So instead of doing a GET on the socket path and directly upgrading to a websocket you go to a ‘basic’ route with the first GET, then you authenticate the JWT from the header, if OK you generate a phoenix token and redirect to your socket path with a query param set to that phoenix token (which is only valid for a short time (minutes)). One of the advantages of doing it this way is that error handling of the socket upgrades is almost non-existent (per the websocket RFC standard). Disadvantage is the extra ‘hop’ / redirect that you do extra but could be a small price given that websockets have a single authentication for the duration of the whole connection. Not sure if this works well with other transports, should work with at least Websockets as transport. (good point of LostKobrakai about the why behind all of this)

2 Likes
12

So, how can we intercept a socket connection in Elixir to perform security checks, before it reaches the Phoenix Channels layers?

13

If I understand you this means an HTPP redirect, therefore defeating the security that the Third Party integration is meant to bring to the API.

14

Intercepting is the wrong approach imo. Transports are the implementation mapping from whatever network communication you use to the higher level channel. Instead of trying to intercept the implementation phoenix ships you can write your own implementation, which does deal with the connection of your third party API exactly as it’s needed. No need to intercept anything.

1 Like
15

So, your suggestion is that I should implement the Phoenix.Socket.Transport behavior and then I may want to use the connect/1 to check the token?

16

Exactly.

1 Like
17

This approach doesn’t work. I have no access to the Plug.Conn, therefore no access to the headers, thus cannot check the token.

Any other suggestions?

18

This is a bad practice in terms of security, therefore this will be the very last approach I will try.

19

Tried it, but doesn’t work. The x-header is correctly set in the conn but I cannot see it in the websocket connect/3.

  plug :x_approov_token_header

  def x_approov_token_header(conn, _opts) do
    [{_header, value} | _ ] = for {header, _} = pair <- conn.req_headers, header in ["approov-token"], do: pair

    Plug.Conn.put_req_header(conn, "x-approov-token", value)
  end

  socket "/socket", EchoWeb.UserSocket,
  # socket "/socket", ApproovSocketTransport,
    websocket: [
      compress: true,
      connect_info: [
        :peer_data,
        :trace_context_headers,
        :x_headers,
        :uri,
      ],
      check_origin: {EchoWeb.AuthController, :check_socket_origin?, []}
    ],
    longpoll: false
20

Seems like I have misunderstood how the system works to a degree. I was looking at this one, which indeed has the conn available:

1 Like