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

[FIXED] Validation in jetstream and KV #1613

Merged
merged 4 commits into from
Apr 22, 2024
Merged

[FIXED] Validation in jetstream and KV #1613

merged 4 commits into from
Apr 22, 2024

Conversation

piotrpio
Copy link
Collaborator

Signed-off-by: Piotr Piotrowski piotr@synadia.com

Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
@piotrpio piotrpio requested a review from Jarema April 17, 2024 10:26
kv.go Outdated
validKeyRe = regexp.MustCompile(`\A[-/_=\.a-zA-Z0-9]+\z`)
validBucketRe = regexp.MustCompile(`\A[a-zA-Z0-9_-]+\z`)
validKeyRe = regexp.MustCompile(`\A[-/_=\.a-zA-Z0-9]+\z`)
validSearchKeyRe = regexp.MustCompile(`^[^ >]*[>]?$`)
Copy link
Contributor

Choose a reason for hiding this comment

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

this would allow matching keys that arent valid keys like x!y

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You're right, I'll just base it on validKeyRe + allow wildcards

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Changed to ^[-/_=\.a-zA-Z0-9*]*[>]?$

Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
if dur == "" {
return fmt.Errorf("%w: '%s'", ErrInvalidConsumerName, "name is required")
}
if strings.ContainsAny(dur, ">*. /\\") {
Copy link
Member

Choose a reason for hiding this comment

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

This now is aligned with CLI and .js clients, but I'm afraid implementing this change could break some users.
Any thoughts @ripienaar ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, perhaps the only one the server wouldnt catch really is the space right?

Copy link
Contributor

Choose a reason for hiding this comment

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

actually no - space would break the protocol there so that wouldnt have worked, I think its fine but we do need to call it out carefully

Copy link
Member

Choose a reason for hiding this comment

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

we definately need to add space and wildcards, but / and \ are not that obvious IMO.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

/ and \ are already rejected by the server with API error: code=400 err_code=10128 description=Stream name can not contain path separators (same for consumer names), so the only change here would be client-side validation instead of server-side. But I don't think we absolutely need it since this at least does not break protocol when put in subject.

Copy link
Member

Choose a reason for hiding this comment

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

qq, when creating a consumer do we check for whether trying to create an filter subject like foo.>. or foo.>.*?

Copy link
Collaborator Author

@piotrpio piotrpio Apr 17, 2024

Choose a reason for hiding this comment

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

We don't. I assume safe validations (100% non-breaking) would be checking for > and . placements right? Plus spaces in subject. Anything else?

Copy link
Member

Choose a reason for hiding this comment

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

yes ending with . need to be client side since it becomes a malformed subject so the server cannot match the JS API, foo.>.* looks like the server does handle

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added validating filter subject

@@ -344,8 +344,9 @@ const (

// Regex for valid keys and buckets.
var (
validBucketRe = regexp.MustCompile(`\A[a-zA-Z0-9_-]+\z`)
validKeyRe = regexp.MustCompile(`\A[-/_=\.a-zA-Z0-9]+\z`)
validBucketRe = regexp.MustCompile(`^[a-zA-Z0-9_-]+$`)
Copy link
Member

@Jarema Jarema Apr 17, 2024

Choose a reason for hiding this comment

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

I would test thse regex expressions (or better - a functin that valide those items).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Tests added

Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
@Jarema
Copy link
Member

Jarema commented Apr 19, 2024

@ripienaar you're fine with the current state of this PR after recent changes?

@ripienaar
Copy link
Contributor

@Jarema i think so yes

Copy link
Member

@Jarema Jarema left a comment

Choose a reason for hiding this comment

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

LGTM

@piotrpio piotrpio merged commit 7bdb629 into main Apr 22, 2024
2 checks passed
@piotrpio piotrpio mentioned this pull request May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants