search

lihaoquan / pe

0 stars 0 forks source link

Through the addstu command, an invalid email can be assigned to a student #7

Open lihaoquan opened 3 months ago

lihaoquan commented 3 months ago

Through the command addstu n/Johnny nn/E9381920 e/e@oe I was able to add a student with the email e@oe which does not fit the specifications as shown in the message bar: image.png

The violation is shown in the following picture: image.png

Email validation may need to be strengthened to fit the specifications shown in the message bar.

nus-pe-bot commented 3 months ago

Team's Response

This issue is on the error message result being incorrect for email.

The reason why this issue could be rejected, is because e@oe follows the specifications mentioned.

It doesn't violate any of the specifications mentioned, so we could reject this.

Moreover, if we are more strict with The domain name is made up of domain labels separated by periods, to imply that there is should be more than one domain label in the domain name, then it is possible that it could be interpreted either way.

Therefore, we put this as very low, as the situation when this occurs is rare, most domains have more than one domain label, so most users would not be bothered by this.

Side note: e@oe is a valid email address when we use a top-level domain as the domain name, so the title of the issue is incorrect. See domain names allowed by RFC5321.

This is a duplicate of 166, since the issue origins from the error message for email.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Through the Edit command, invalid email can be assigned to a student

By using the following command: edit 1 e/e@oe

An invalid email that does not fit the following description: image.png

is able to be assigned to a student as shown: image.png

The email validation mechanism may need to be further strengthened to prevent such email from being assigned to students.

[original: nus-cs2103-AY2324S2/pe-interim#133] [original labels: type.FunctionalityBug severity.Low]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

This issue is on the error message result being incorrect for email.

The reason why this issue could be rejected, is because e@oe follows the specifications mentioned.

  • e is the local part, which contains only alphanumeric characters.
  • oe is the domain. oe is a domain label in the domain. It is at least 2 characters long, starts and ends with alphanumeric characters, and consists of alphanumeric characters.
  • The domain name is made up of domain labels separated by periods. This means that if there is only one label, then no periods would need to separate the domain name.

It doesn't violate any of the specifications mentioned, so we could reject this.

Moreover, if we are more strict with The domain name is made up of domain labels separated by periods, to imply that there is should be more than one domain label in the domain name, then it is possible that it could be interpreted either way.

Therefore, we put this as very low, as the situation when this occurs is rare, most domains have more than one domain label, so most users would not be bothered by this.

Side note: e@oe is a valid email address when we use a top-level domain as the domain name, so the title of the issue is incorrect. See domain names allowed by RFC5321.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]