Check for 403 response on socket client?

The same issue. Any ideas?

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.

With websocket, I think we actually can put something here, in the 403 body:
https://github.com/phoenixframework/phoenix/blob/5d90892e32cae195b8235fb921666cd016fef111/lib/phoenix/transports/websocket.ex#L86

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

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.

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.

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

I so love when someone says that. ^.^

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.

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:

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

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

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.