Add additional validation rules

[brendt]

Each of these rules should implement the Rule interface, and have a test to validate it works as expected. Keep in mind that Tempest relies on PHP's type system for rudimentary validation like required, nullable, and type. These shouldn't be validation rules.

• Alpha - all characters are letters [A-Za-z] (added: Alpha and AlphaNumeric rules. #69)
• AlphaNumeric - all characters are alphanumeric (added: Alpha and AlphaNumeric rules. #69)
• Count — an array with a min/max count
• Email — a valid email address
• Enum — a valid enum value (Adds enum validation rule #68)
• Length — a string with a min/max length
• PhoneNumber — a valid phone number
• Between — an integer between two values, edges included
• Boolean (Adds boolean validation rule #76)
• ShouldBeTrue — a value that represents a boolean true value. (Add ShouldBeTrue and ShouldBeFalse validation rules #64)
• ShouldBeFalse — a value the represents a boolean false value (Add ShouldBeTrue and ShouldBeFalse validation rules #64)
• Url — a valid URL
• Date — a valid date we can use DateTimeFormat?
• Time — a valid time (Adds time rule #67)
• DateTimeFormat — a valid date/date time with a specific format (Add Date validation rule #53)
• Timestamp — a valid timestamp (integer)
• Timezone - a valid timezone
• Regular Expression — value matches the regular expression passed (Adds regex validation rule #72)
• StartsWith - starts with the specified string (Add StartsWith validation #74)
• EndsWith - ends with the specified string (UPPERCASE/lowercase rules #82)
• DoesNotStartWith - does not start with the specified string
• DoesNotEndWith - does not end with the specified string
• Uppercase - is UPPERCASE (UPPERCASE/lowercase rules #82)
• Lowercase - is lowercase (UPPERCASE/lowercase rules #82)
• UUID - is a valid UUID
• ULID - is a valid ULID
• IP Address - is a valid IP address
• MAC Address - is a valid MAC address
• Password - Allows the specification of password complexity with some sensible defaults
• PasswordNotCompromised - Checks the password against haveibeenpwned not right now
• SameAs — this value should be the same as another value, for example for password validation skip for now since Rules aren't aware of their larger context.

[aidan-casey]

@brendt - it might be helpful to flesh out exactly which rules we'd need to see in place before v1. Gives people something to work toward. 🙂

[brendt]

I'll draft a list later today or tomorrow :)

[aidan-casey]

@brendt - I'm thinking we should update the rule interface to simply accept the object under validation as an additional parameter. Any reason you can think of not to do this vs. something like a separate data aware interface like Laravel has?

[brendt]

Do you have an example of when it might be useful? My intention for validation rules was that they would be an extension on PHP's type system without the need for any additional context. But I'm open for exploring alternatives

[aidan-casey]

The SameAs rule will require the greater context of the object, unless you want to engage wizardry mode.

[aidan-casey]

@brendt - I am going to expand your list every time we get close to finishing it. 😉

[brendt]

Btw, if SameAs is the only rule that requires context, then we should skip it for now. There are other solutions to solving it which are convenient enough.

[aidan-casey]

Alpha / AlphaNumeric were added in #69.

[aidan-casey]

@brendt - should Tempest be supporting conditional validation rules?

For example, if I want the value to be a URL OR IP address?

[brendt]

Not right now, I don't think it's needed for 1.0.

[omerimzali]

@brendt PasswordNotCompromised - Checks the password against haveibeenpwned
For this validation rule are you planning to send a request to haveibeenpwned? Or is there another solution to this issue, such as searching through a local list? If we need to make the request, would curl be appropriate? Or would you consider using Guzzle? The project has not used either of them before.

[brendt]

I believe it's indeed a request to haveibeenpwned. We can always look at how Laravel and Symfony implement those rules, to be sure.

The question about which HTTP client to use is actually an interesting one. I'm sure we shouldn't use curl directly, so maybe guzzle; but I really dislike the overhead that comes with PSR support in guzzle. Maybe let's not work on this rule until we've figured out which HTTP client we want to use throughout Tempest.

[omerimzali]

Would you consider doing Msisdn validation? Phone numbers are as commonly used as email. I'd like to create that validation, If you consider to add.

[aidan-casey]

@omerimzali I believe this is covered by the PhoneNumber rule, no?

[omerimzali]

@aidan-casey Yes you're totally right. I was mistaken as I was searching for the term "msisdn validator".

[aidan-casey]

@omerimzali - Perfect! I will try to remember mentioning MSISDN in the docs so it is easily searchable. 🙂

[aidan-casey]

I believe it's indeed a request to haveibeenpwned

See more details here on the API for checking password hashes.

Maybe let's not work on this rule until we've figured out which HTTP client we want to use throughout Tempest.

I think this is an accurate thought. 🙂

[brendt]

I think this one is ready to be closed 🥳 Thanks a lot to everyone helping out!