-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wait for auth multiplex #31
Conversation
Whenever a client calls the authenticate method, or receives a successful handshake, or gets a #setAuthToken, the auth state is set to true. When a client is disconnected or an auth token is removed, or an auth token expires, the isAuthorized state turns false. Also, performs check for malformed tokens before sending them to the server.
Use case: create a connection, dirty it up with callbacks, extra props, etc, disconnect. Connect again, you still have dirty callbacks. Better to destroy.
Continued from #28 |
Regarding |
Additionally, we could store the token itself in the socket object. The AuthEngine would save the token, but when we need the token, we get it direct from the object. One thing to note is that since the handshake happens on the transport layer, we'd either have to save it there, or have the transport layer depend on the socket layer, so it doesn't really affect this issue. |
I merged most of the commits. I left out the bits related to the isAuthenticated state since this is likely to change in v4. For the expiry case, I think the server should tell the client when the token has expired (E.g. when the token-expiry middleware will emit a This has been published in v3.1.0 on npm and bower. |
I'm closing this since this has been manually merged. Feel free to keep this branch in your fork if you feel that this other (unmerged) code might be useful as part of v4 release. I prefer if the client is optimistic about its isAuthenticated state and let the server correct it (E.g. using a deauthenticate event) if it is not accurate. With this approach, we might get false positives (whereby an unauthenticated client wrongly believes that it is authenticated), but we would never get false negatives. False positives can be easily corrected (using the deauth event or a token expired error). If we let the client do expiry on its own, we might end up with false positives OR false negatives depending on whether the client's clock is ahead or behind the server time and this complicates things. |
Sorry for combining issues, but there was a bit of overlap.
First up fixes #27. The external API doesn't change, but behind the scenes it caches connections based on url. Also offers up a
multiplex
option if you don't want to cache your connection. Finally, it offers adestroy
method. you'd call it just like connect, egsocketCluster.destroy(options)
. It looks up the id based on your options & deletes it from the cache.Second fixes #29
First, it puts 2 props on SCSocket:
isAuthenticated (boolean)
and_tokenExpiration (timeoutHandler)
.On every successful handshake,
#setAuthToken
, andauthenticate
method, it setsisAuthenticated
to true & calculates the time to live for that to remain true. Once that time is up, it turns false.Also, on every disconnect or
#removeAuthToken
it turns false.Additionally, I added a safety check to make sure the token is legit before it's sent off to the server.
With that in place, it adds on
options
argument to thesubscribe
method. ifwaitForAuth
is true, then it waits. before subscribing.