-
Notifications
You must be signed in to change notification settings - Fork 252
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
fix(rumqtt): validate topic and topic filter #813
base: main
Are you sure you want to change the base?
Conversation
note that it won't fix #595 as broker still doesn't perform the checks, and doing that in separate PR is preferable. I would recommend to remove that from PR description so it won't automatically close the issue if this PR is merged. |
It is still an ongoing work. Since broker will perform the same task, I will implement it in this PR itself. |
Pull Request Test Coverage Report for Build 8519279552Details
💛 - Coveralls |
(is_topic_valid || is_topic_empty) | ||
&& (!is_topic_empty || is_alias_given) | ||
&& (!is_alias_given || is_alias_valid) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo this is harder to read in comparison to if...else branch, wdyt @swanandx?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some investigation. It seems that apart from the length of the function, the assembly for if-else version of validate_topic_name_and_alias
remains the same. How should we proceed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution.
Is there a benchmark somewhere? The topic validation is in the hot path and must not have any crucial performance impact.
Hello @flxo. The hot paths that you mention use generic functions (eg. Also feel free to review the changes and suggest any scope of improvements, should you happen to find any. |
Sure - this all helps. I'm just curious if someone used e.g criterion to verify that best effort is done.
Sure. |
@@ -16,8 +37,9 @@ pub fn valid_topic(topic: &str) -> bool { | |||
/// Checks if the filter is valid | |||
/// | |||
/// <https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718106> | |||
pub fn valid_filter(filter: &str) -> bool { | |||
if filter.is_empty() { | |||
pub fn valid_filter(filter: impl AsRef<str>) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd name this is_filter_valid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it is a public function, we may run into the risk of backwards incompatibility due to name change. What do you think?
@@ -34,6 +35,10 @@ pub fn read( | |||
bytes.advance(variable_header_index); | |||
let topic = read_mqtt_bytes(&mut bytes)?; | |||
|
|||
if !valid_topic(from_utf8(&topic).map_err(|_| Error::TopicNotUtf8)?) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the validation is done (again) when obtaining len
. This can be a problem when len
is used during encoding since the utf8 check is not cheap at all.
Have you thought about a TryFrom
impl for all the packet types in here? Validate the parameters once at construction time (and maybe precalculate the length once.
…ing to MQTTv3 spec
refactor(v5/client): use descriptive variable name
…ghput in hotspots
1afd63e
to
6d30795
Compare
Type of change
Checklist:
cargo fmt
CHANGELOG.md
if it's relevant to the users of the library. If it's not relevant mention why.Fixes #595