Check for 403 response on socket client?

channels
phoenix

#1

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!


#2

The same issue. Any ideas?


#3

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. :frowning:


#4

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

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).


#5

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.


#6

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:

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


#7

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

#8

I so love when someone says that. ^.^


#9

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.