Check for 403 response on socket client?

shosti · October 13, 2016, 8:04pm

I have a socket/channel setup with some custom authentication logic. If the authentication fails, it shows an error message to the user (so they can fix the problem). Right now this is handled at the channel level–basically all socket connections are accepted, but only properly authenticated sockets can join particular channels.

I’d prefer to move auth checking to the socket level, so unauthenticated connections get refused with a 403 (that would prevent accidental and/or malicious unauthed connections from holding unnecessary socket connections). The problem I’m running into: socket authentication failures seem to be handled the same way as “normal” connection failures by the client (triggering onClose and onError with generic close events, starting retries, etc.).

So my question: is there any way to have custom handling for socket authentication errors on the client side? I’d like “normal” connection failures to use the default behavior (retries, etc.) but authentication failures to not retry and instead alert the user. Thanks in advance!

Stingray · January 29, 2017, 4:58pm

The same issue. Any ideas?

josevalim · January 29, 2017, 6:39pm

If I remember correctly, it is not possible to do so because browsers do not provide enough information to the client in a way we can inform what went wrong, unfortunately.

Kabie · March 15, 2017, 7:06am

With websocket, I think we actually can put something here, in the 403 body:

github.com

phoenixframework/phoenix/blob/5d90892e32cae195b8235fb921666cd016fef111/lib/phoenix/transports/websocket.ex#L86




  case conn do
    %{halted: false} = conn ->
      params     = conn.params
      serializer = Keyword.fetch!(opts, :serializer)


      case Transport.connect(endpoint, handler, transport, __MODULE__, serializer, params) do
        {:ok, socket} ->
          {:ok, conn, {__MODULE__, {socket, opts}}}
        :error ->
          send_resp(conn, 403, "")
          {:error, conn}
      end
    %{halted: true} = conn ->
      {:error, conn}
  end
end


def init(conn, _) do
  send_resp(conn, :bad_request, "")
  {:error, conn}

Not sure how LongPoll should handle this though.

It seems that browser does not have the access to the websocket request and response. Can we allow a case {:error, reason} here, only for a non-browser client (which is my case).

chrismccord · March 15, 2017, 12:36pm

As far as I’m aware, the browser WebSocket clients have no way to access the body of the handshake response, so this wouldn’t help us.

Kabie · March 16, 2017, 6:27am

Yes, I understand that. However, clients other than a browser may have access to that, which is my case.

I can write a Transport replacing Phoenix.Transports.WebSocket, but I can only returns {:ok, socket} or :error in connect:

github.com

phoenixframework/phoenix/blob/5d90892e32cae195b8235fb921666cd016fef111/lib/phoenix/socket/transport.ex#L179


    {:ok, socket} ->
      case handler.id(socket) do
        nil                   -> {:ok, socket}
        id when is_binary(id) -> {:ok, %Socket{socket | id: id}}
        invalid               ->
          Logger.error "#{inspect handler}.id/1 returned invalid identifier #{inspect invalid}. " <>
                       "Expected nil or a string."
          :error
      end


    :error ->
      :error


    invalid ->
      Logger.error "#{inspect handler}.connect/2 returned invalid value #{inspect invalid}. " <>
                   "Expected {:ok, socket} or :error"
      :error
  end
end


@doc """

I’m asking can we allow a {:error, reason} case here, so a Transport can leverage that.

GregMefford · March 1, 2018, 4:41am

I was unwilling to accept that this is impossible, so I’ve come up with the following hack that works to resolve the issue of a Phoenix Socket that has an expired authentication token, causing it to return a 403 when the client tries to reconnect. This happens, for example, when the user has left a page open for hours on end, so the token is expired, but the Phoenix Channel client is still trying to reconnect and the page itself is still loaded in the browser, so it has no idea that its token is expired.

Each time it tries and fails to connect, it generates an event that can be captured with a socket.onError callback. The problem is that this event doesn’t have any useful information in it about why the connection failed. We can see that the reason is because the connection 403ed in the Chrome dev tools, but JavaScript can’t see that error message. The hack is to have a callback that makes an AJAX call to the server, being sure to send credential cookies like you normally would, and check whether it gets redirected to your login page. This obviously assumes that the AJAX call you make would get redirected if you’re not logged in, and would not get redirected if you’re already logged in.

In this case, I’m just reloading the page when I detect this condition (which will cause me to get redirected to login again), but you could do whatever you need to do in JavaScript-land.

Pardon my terrible JavaScript; hopefully you can find the meaning beneath the madness.

const reloadOnRedirect = () => {
  fetch('/', {credentials: 'same-origin'})
    .then((response) => { if (response.redirected) window.location.reload() });
}

// Normal Socket setup code ...

socket.onError(reloadOnRedirect);
socket.connect

OvermindDL1 · March 1, 2018, 5:17pm

I so love when someone says that. ^.^

norpan · February 11, 2019, 9:26am

I’m battling with the same problem. My solution is to not have authentication on the socket connection, but move it to the channels. Specifically to the “general” channel. If there is no authentication information, the channel will send an “unauthorized” response, which will trigger the login process again.

paulstatezny · February 5, 2020, 5:02pm

I’ve ran into the same exact problem.

Since JWT tokens can be inspected / the data pulled out, I’m going to check my refresh token’s exp claim to determine if it’s expired. (Probably with a clock drift tolerance; meaning if it expires in the next ~30 seconds I count it as expired.)

Then I’ll add an onError or onClose handler that:

Checks if our current token is expired.
If so, refreshes and then re-creates the Socket object with the new credentials in the params.
If not, just no-ops.

Slightly inefficient / hacky feeling, but it should work. I’ll report back with the results.

OvermindDL1 · February 14, 2020, 5:41pm

JWT tokens are generally supposed to have a very short life, like 30 seconds to a minute max is usual, anything longer is almost certainly a misdesign as it makes it easier to reuse, so be careful with it.

iwarshak · May 7, 2020, 9:46pm

Did you have any luck with this? It seems inefficient that unauthenticated users (or users that have had their session time-out) keep trying to reconnect.

I agree that there should be a way to prevent the socket from being opened in a way that lets the client know it does not need to keep trying.

juanpabloaj · May 24, 2020, 3:58pm

to reproduce the problem in a development environment

diff --git a/config/dev.exs b/config/dev.exs
index 7feeef0..17e8dfd 100644
--- a/config/dev.exs
+++ b/config/dev.exs
@@ -12,0 +13,4 @@ config :myapp, Myapp.Repo,
+secret_key_base =
+  System.get_env("SECRET_KEY_BASE") ||
+    :crypto.strong_rand_bytes(64) |> Base.encode64() |> binary_part(0, 64)
+
@@ -22 +26 @@ config :myapp, MyappWeb.Endpoint,
-  code_reloader: true,
+  code_reloader: false,
@@ -23,0 +28 @@ config :myapp, MyappWeb.Endpoint,
+  secret_key_base: secret_key_base,

bjunc · May 26, 2020, 2:30pm

Just my 2c, but not everyone shares this sentiment. JWT are often used for much longer durations.

A quite common OAuth API convention uses a 60 min JWT expiration for authorization, with a much longer lived refresh token (which is also a JWT).