freshcabbage123 / pe

0 stars 0 forks source link

Weak email validation regex #5

Open freshcabbage123 opened 11 months ago

freshcabbage123 commented 11 months ago

Screenshot 2023-11-17 at 4.25.27 PM.png

There is no warning to suggest that emails lacking in top level domain (e.g. .com) are allowed to be added. Perhaps a stronger email validation regex should have been in place or there should have been a clearer warning to the user in the UG just like support for slashes for adding a person. It is not merely a cosmetic issue so low severity

soc-se-bot commented 11 months ago

Team's Response

There exist valid email addresses without .com. Refer to the following link:

https://en.wikipedia.org/wiki/Email_address#Examples

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: The team's response points out that email addresses without a top-level domain (TLD) are valid, citing examples of local domain emails without TLDs. While this is technically correct, it is crucial to consider the application's target user base and the most common use cases when implementing validation rules. The target user is for students and most student emails have a TLD such as our default NUSNET emails.

In most practical scenarios, especially for applications intended for a general audience, email addresses without a TLD are atypical. The vast majority of users will be utilizing standard email formats that include a TLD. Therefore, while it's important to support a range of email formats, it's also essential to guide users towards the expected and most commonly used formats.

A strong argument can be made for implementing a validation system that, by default, expects a TLD, but provides an override option for the less common cases where a TLD is not present. Additionally, clear communication in the user guide about the types of supported email formats would be beneficial. This would prevent confusion and ensure that users are aware of the application's capabilities and limitations regarding email address formats.

Moreover, the lack of a clear warning or message when an atypical email format is entered can lead to user confusion. If a user unknowingly enters an email address without a TLD, they might expect the application to function normally, potentially leading to communication issues down the line. Thus, it is not solely a cosmetic issue, but one that can impact the application's functionality and the user's experience.


## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]