Skip to content
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

[MM-42712] Implement basic rate limiting for incoming WebSocket messages #51

Merged
merged 1 commit into from
Apr 28, 2022

Conversation

streamer45
Copy link
Collaborator

Summary

I've tested this locally and while this is surely better than nothing, it feels like a proper solution should be either implemented on the server side or we should find a way to allow a plugin to disconnect a malicious connection. As things stand a high rate of messages will still produce some noticeable load given the events are routed to the plugin with RPC calls happening and all that's involved into that process.

Please let me know your thoughts.

Ticket Link

https://mattermost.atlassian.net/browse/MM-42712

@streamer45 streamer45 added 2: Dev Review Requires review by a core committer 3: Security Review labels Apr 27, 2022
@streamer45 streamer45 requested review from cpoile and oh6hay April 27, 2022 16:50
@streamer45 streamer45 self-assigned this Apr 27, 2022
Copy link
Member

@cpoile cpoile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose a proper server side solution would be better after we move into the sever? Seems fine for now. :)

@streamer45
Copy link
Collaborator Author

I suppose a proper server side solution would be better after we move into the sever? Seems fine for now. :)

Yes, we could work something with Server Platform team and find a way to extend the existing rate limiter to address WebSocket events as well but the limit may be app/plugin specific so best solution is to keep the check there I feel.

Exposing a way to trigger a disconnect would be an interesting approach but again it would require some coordination and likely bumping minimum server version as well. Within the current timeline I think this as a patch but happy to freeze it as well if it's not deemed worth it from a security perspective.

Copy link

@oh6hay oh6hay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@streamer45 streamer45 added 3: Reviews Complete All reviewers have approved the pull request Do Not Merge/Awaiting PR Awaiting another pull request before merging (e.g. server changes) and removed 2: Dev Review Requires review by a core committer 3: Security Review labels Apr 28, 2022
Base automatically changed from rtcd to main April 28, 2022 11:06
@streamer45 streamer45 removed the Do Not Merge/Awaiting PR Awaiting another pull request before merging (e.g. server changes) label Apr 28, 2022
@streamer45 streamer45 merged commit f252b1e into main Apr 28, 2022
@streamer45 streamer45 deleted the MM-42712 branch April 28, 2022 11:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3: Reviews Complete All reviewers have approved the pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants