Stop trying to reconnect on unauthorized cable connections

[staugaard]

Summary

When calling reject_unauthorized_connection from an ActionCable::Connection, the client would keep retrying to establish a connection. These would keep failing as the client is still unauthorized.

This stops that. If you call reject_unauthorized_connection, the connection is now closed and is not retried.

[rails-bot]

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

[staugaard]

Not sure what to do to get some eyes on this? @schneems?

[taleh007]

Not sure what to do to get some eyes on this? @schneems?

You can do nothing. I think he is very busy man

[jeremy]

/cc @rmacklin @palkan 😅

[palkan]

💯 for this feature! @staugaard thanks!

Few other thoughts:

• What about making a message type more generic name? I would suggest smth more low-level with additional customizable fields, like { "type": "disconnect_notice", "reconnect": false, "reason": "Unauthorized" }
  • or we can allow to customize the message through reject_unauthorized_connection("You are not authorized")
• It would be great to make it possible to notify client about not-reconnecting when using ActionCable.server.remote_connections.where(current_user: User.find(1)).disconnect
  • e.g. disconnect(reconnect: false, reason: "human-friendly error to show to the user")
• I think, we should provide an API to catch this disconnect event on JS consumer, e.g. ActionCable.onDisconnect(msg)

[rmacklin]

I think the reason I was mentioned may be because this would cause a significant conflict with my open pull request: #34177

I just addressed the last comment on the PR so I'm hoping that we'll be able to merge it soon. So, do we think it's reasonable to wait to merge this PR until that ES2015 conversion is merged?

[staugaard]

I'll happily rebase on master once #34177 is merged.

[rmacklin]

I'm happy to help if you'd like

[staugaard]

OK @palkan, @rmacklin, and @schneems. I've rebased on master since #34177 was merged. Good to go?

[jeremy]

@palkan Regarding your three thoughts: which should be addressed in this PR, and which are topics for further PRs?

[palkan]

@jeremy

I think, it makes sense to define on the message type (and meta information along with this message). I mean:

What about making a message type more generic name? I would suggest smth more low-level with additional customizable fields, like { "type": "disconnect_notice", "reconnect": false, "reason": "Unauthorized" }

WDYT?

Others two could be added later separately and shouldn't block this PR, IMO.

[staugaard]

Something like this @palkan ?

[palkan]

Something like this @palkan ?

Yep. Looks good 👍

[staugaard]

OK, I think we are good to go on this one then. Should I squash?

[staugaard]

@schneems ?

[taleh007]

@schneems ?

no way to catch him online

[mlwilkerson]

@staugaard How might the JavaScript client be able to respond to this event?

I've been trying to figure out an elegant-ish way to add a short-lived access token to the cable URL as a GET param, updating the cable url when a refreshed access token comes back in a custom header. (I'd much prefer to add a custom HTTP header, as with a normal JWT auth token, but that doesn't seem to be an option here in the WebSocket world). Most of the time this works, except apparently in some cases where the ConnectionMonitor/reopen logic happens out of band with the access token refresh logic. In that case, it just tries forever to reconnect with an old access token. So this feature where the server sends back a distinct message about the unauthorized connection to stop reconnect attempts is helpful. But then I'd need the client to be able to respond to that event by getting a refreshed access token, rebuilding the cable url with it, and then trying again to connect.

[rafaelfranca]

Could you squash and add a CHANGELOG entry?

[staugaard]

@rafaelfranca @schneems, I squashed and added CHANGELOG entry.

[staugaard]

This is taking you guys a while. Now there is a conflict. I'll rebase.