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

Add an option to limit number of errors returned #1017

Merged
merged 6 commits into from
Jun 15, 2023

Conversation

bc-dima-pasieka
Copy link
Contributor

What?

Add an option to limit the number of errors returned.

Why?

There is a possibility that the lack of limits could be abused to induce memory pressure in the server/service handling the request and can lead to the potential denial of service (i.e. no DDoS needed).

@yanns
Copy link
Contributor

yanns commented Jun 13, 2023

thanks for this PR. 💯
There are some binary breaking changes (default values are set at caller site).

I think that we add some methods to avoid some of those

  • apply(rules: List[ValidationRule]): RuleBasedQueryValidator in the companion object
  • a similar apply in ValidationContext

Would you take care of it or should I?

@@ -148,7 +156,8 @@ class ValidationContext(
val schema: Schema[_, _],
val doc: ast.Document,
val sourceMapper: Option[SourceMapper],
val typeInfo: TypeInfo) {
val typeInfo: TypeInfo,
errorsLimit: Option[Int] = None) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Making errorsLimit immutable as ValidationContext is a call.

Suggested change
errorsLimit: Option[Int] = None) {
val errorsLimit: Option[Int] = None) {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

omitting val will make it private to the class since it's not a case class, won't it? 🤔 Do we want to make it public?

Copy link
Contributor

Choose a reason for hiding this comment

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

oh yes sorry. Keep it like this.

@bc-dima-pasieka
Copy link
Contributor Author

apply(rules: List[ValidationRule]): RuleBasedQueryValidator in the companion object

It looks like it will be a breaking change if we do it this way - we will not be able to call new RuleBasedQueryValidator(newRules) anymore (only RuleBasedQueryValidator(newRules))

object RuleBasedQueryValidator {
  def apply(rules: List[ValidationRule]): RuleBasedQueryValidator = RuleBasedQueryValidator(rules, None)
}

The same with ValidationContext.

🤔 Would we be fine introducing breaking change?

@yanns
Copy link
Contributor

yanns commented Jun 13, 2023

RuleBasedQueryValidator is more likely being called from user.
Sure that we cannot keep the new RuleBasedQueryValidator(rules), but let's try to keep the apply method.

For ValidationContext, I think it's ok to make a breaking change. It's unlikely that users initiate it themselves.
I'll add this to the release notes.

@bc-dima-pasieka
Copy link
Contributor Author

@yanns let me know if it looks better now 🙌

@yanns
Copy link
Contributor

yanns commented Jun 15, 2023

It's looking good, thanks!
I'll take care of adding exceptions for the rest of binary incompatibilities,

@yanns
Copy link
Contributor

yanns commented Jun 15, 2023

I propose to set a default limit to make default usage safe: aab5f5b
WDYT? 10 errors are sufficient?

1 similar comment
@yanns
Copy link
Contributor

yanns commented Jun 15, 2023

I propose to set a default limit to make default usage safe: aab5f5b
WDYT? 10 errors are sufficient?

@bc-dima-pasieka
Copy link
Contributor Author

10 sounds like a good default value! 👍

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.

2 participants