Open KUSHAGRARAJTIWARI opened 11 months ago
Let's put this behind a new option for backwards compatibility. Some projects might use both for user input and then they expect a boolean returned instead of an error.
So isHash would get an option bag which consists of validateAlgorithm
. I would recommend setting the default to true, and then people can set it to false if they don't want this new validation
Let's put this behind a new option for backwards compatibility. Some projects might use both for user input and then they expect a boolean returned instead of an error.
So isHash would get an option bag which consists of
validateAlgorithm
. I would recommend setting the default to true, and then people can set it to false if they don't want this new validation
Can you please add an enhancement label to this issue and assign it to me?
Let's put this behind a new option for backwards compatibility. Some projects might use both for user input and then they expect a boolean returned instead of an error.
So isHash would get an option bag which consists of
validateAlgorithm
. I would recommend setting the default to true, and then people can set it to false if they don't want this new validation
so, if validateAlgorithm is set to true, should the function throw an error saying "Invalid algorithm" and return false?
If it's set to true it should throw an Error, if it's set to false it will return false (the current behaviour)
@WikiRik PR for enhancement suggested. Please review. https://github.com/validatorjs/validator.js/pull/2296
@WikiRik I suggest having validation on the parameter algorithm in the isHash function. The behavior below is not appropriate. The user of validator.js should get a proper error message. [Good for debugging]
Should I raise a pull request? It can be an enhancement.