shosti

Check for 403 response on socket client?

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!

13 comments

/phoenix #channels

1 6199 13

2021-07-10 01:36:55 UTC

Marked As Solved

josevalim

Creator of Elixir

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.

Post #2

Also Liked

GregMefford

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

Post #6