phollyer
Channels. What strategy when connection is denied
There are two different scenario’s I’m trying to handle with the Phoenix JS Websocket client - both produce the same result but I need to handle them both differently.
1. The application is not accessible/responding.
2. Denying a user connection due to failing authentication.
I am authenticating and then denying connection as per the comments for UserSocket.connect/2:
# To deny connection, return `:error`.
1 socket.onError() fires and the socket tries to reconnect again. This is the expected behaviour and is what would be wanted in this scenario.
2 socket.onError() fires and the socket tries to reconnect again. This is not the behaviour I would expect or want. If connection is denied due to failing authentication, then I would not want the socket to keep trying to connect.
If I call socket.disconnect() when the connection is denied, then this stops the repeated attempts to connect again (which seems strange as the socket hasn’t connected yet). This is fine for 2, but not what I would want for 1.
So how do you differentiate between to the two scenarios? Both scenarios fire the same callback function but with no useful data to know which scenario is being responded to?
Or am I looking at this all wrong?
Thanks
Marked As Solved
peerreynders
import {Socket} from "phoenix"
let socket = new Socket("/socket", {params: {token: window.userToken}})
let cancelTimeout = true
function openListener(_event) {
// once successfully opened
// try to reconnect
cancelTimeout = false
}
function closeListener(_event) {
if(cancelTimeout) {
// don't retry as it is likely a failure to authenticate
socket.reconnectTimer.reset() // cancel automatic reconnect
}
}
socket.onOpen(openListener)
socket.onClose(closeListener)
socket.connect()
Unfortunately the WebSocket doesn’t have access to the 403 status code and the CloseEvent code always seems to be 1006 “Abnormal Closure”.
Also Liked
outlog
for technical/specification reasons - you cant know if the onError is called due to wrong auth.. what I do is make an ajax call to “auth_check” and if that fails with 401 - I disconnect, clear the bad token, and navigate to the appropriate place (most likely login screen..) - in any other case I let the reconnect run (as it’s most likely lack of connection or server down that is the issue then)
amnu3387
phollyer
Thanks, makes perfect sense. Hadn’t thought of it that way, such a simple solution. 
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"