javax.validation.constraints.Email совпадает с неверным адресом электронной почты - PullRequest
Новая
       28

javax.validation.constraints.Email совпадает с неверным адресом электронной почты

0 голосов
/ 25 мая 2018

У меня есть объект User, имеющий свойство электронной почты, помеченное @Email

@Email
private String email;

. Я использую аннотацию @Valid (javax.validation.Valid) в своем классе Controller.Проблема заключается в том, что валидатор контроллера передает недействительные электронные письма.Пример:
pusp @ 1 - очевидно, это неверный адрес электронной почты
pusp @ fake
Шаблон, который я заметил, @Email только хочет sometext @ text , это не заботится о расширениях (.com / org и т. Д.).Это ожидаемое поведение?Нужно ли передавать свою собственную реализацию регулярного выражения для @Email(regex="")

1 Ответ

0 голосов
/ 25 мая 2018

Письмо без . может считаться действительным в соответствии с валидаторами.
В общем случае реализации валидатора (здесь это, вероятно, Hibernate Validator) не очень ограничивают электронную почту.
Например,org.hibernate.validator.internal.constraintvalidators.AbstractEmailValidator состояния javadoc:

Спецификация действительного электронного письма может быть найдена в RFC 2822 , и можно найти соответствие регулярного выражениявсе действующие адреса электронной почты согласно спецификации. Однако, как в этой статье обсуждается, не обязательно практично реализовывать 100% -ый совместимый валидатор электронной почты. Эта реализация является компромиссом, пытающимся сопоставить большую часть электронной почты, игнорируя, например, электронные письма сдвойные кавычки или комментарии.

И, как примечание, я заметил аналогичные вещи с HTML Validator для электронных писем.

Так что я думаю, что поведение, с которым вы сталкиваетесь, действительно является ожидаемым.
Ио вашем вопросе:

Нужно ли передавать свою собственную реализацию регулярного выражения для @Email (regex = "")

Действительно.У вас нет другого выбора, если вы хотите сделать проверку более ограничительной.
В качестве альтернативы, этот ответ , создающий собственный валидатор с помощью композиции ограничений, действительно интересен, так как он СУХОЙ (вы можетеповторно используйте ваш пользовательский ConstraintValidator без указания каждого шаблона, в который он будет включен), и он повторно использует «хорошую часть» @Email ConstraintValidator: 

@Email(message="Please provide a valid email address")
@Pattern(regexp=".+@.+\\..+", message="Please provide a valid email address")
@Target( { METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Constraint(validatedBy = {})
@Documented
public @interface ExtendedEmailValidator {
    String message() default "Please provide a valid email address";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}
...