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

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:

https://github.com/phoenixframework/phoenix/blob/5d90892e32cae195b8235fb921666cd016fef111/lib/phoenix/socket/transport.ex#L179

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

The same issue. Any ideas?