हाइबरनेट सत्यापनकर्ता: @Email स्वीकार करता है @ stackoverflow मान्य के रूप में पूछता है?

Question

मैं एक ई-मेल पता सत्यापित करने के लिए @Email एनोटेशन का उपयोग कर रहा हूं। मेरे पास जो मुद्दा है वह यह है कि यह ask@stackoverflow जैसी मान्य ई-मेल पते के रूप में स्वीकार कर रहा है। मुझे लगता है कि ऐसा इसलिए है क्योंकि वे इंट्रानेट पते का समर्थन करना चाहते हैं, लेकिन मुझे ध्वज नहीं मिल रहा है, इसलिए यह एक एक्सटेंशन की जांच करता है।

क्या मुझे वास्तव में @Pattern पर स्विच करने की आवश्यकता है (और एक ई-मेल पैटर्न के लिए कोई अनुशंसा जो लचीला है) या क्या मुझे कुछ याद आ रही है?

Answer 1

वास्तव में, @Email हाइबरनेट वैलिडेटर uses regexp internally से। आप आसानी से कि regexp के आधार पर अपने खुद के बाधा परिभाषित कर सकते हैं संशोधित आप की जरूरत के रूप में (ध्यान दें DOMAIN के अंत में +):

@Target({ElementType.FIELD, ElementType.METHOD}) 
@Retention(RetentionPolicy.RUNTIME) 
@Constraint(validatedBy = {}) 
@Pattern(regexp = Constants.PATTERN, flags = Pattern.Flag.CASE_INSENSITIVE) 
public @interface EmailWithTld { 
    String message() default "Wrong email"; 
    Class<?>[] groups() default { }; 
    Class<? extends Payload>[] payload() default { }; 
} 

interface Constants { 
    static final String ATOM = "[a-z0-9!#$%&'*+/=?^_`{|}~-]"; 
    static final String DOMAIN = "(" + ATOM + "+(\\." + ATOM + "+)+"; 
    static final String IP_DOMAIN = "\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\]"; 

    static final String PATTERN = 
      "^" + ATOM + "+(\\." + ATOM + "+)*@" 
        + DOMAIN 
        + "|" 
        + IP_DOMAIN 
        + ")$"; 
} 

Answer 2

तुम भी रूप में एक काम के आसपास constraint composition उपयोग कर सकते हैं। नीचे दिए गए उदाहरण में, मैं मुख्य सत्यापन करने के लिए @Email सत्यापनकर्ता पर भरोसा करता हूं, और सत्यापनकर्ता को यह सुनिश्चित करने के लिए x@y.z के रूप में यह सुनिश्चित करने के लिए भरोसा करता हूं (मैं नियमित ईमेल सत्यापन के लिए नीचे केवल @Pattern का उपयोग करने की अनुशंसा नहीं करता)

@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 {}; 
} 

Answer 3

बाधा संरचना समाधान काम नहीं करता है। जब पैटर्न पैटर्न के साथ संयोजन के रूप में उपयोग किया जाता है, तो ईमेल regex उच्च प्राथमिकता में आयोजित किया जाता है। मेरा मानना ​​है कि ऐसा इसलिए है क्योंकि ईमेल एनोटेशन कुछ पैटर्न विशेषताओं, अर्थात् झंडे और regexp (यहां कुंजी) को ओवरराइड करता है अगर मैं @Email हटा देता हूं, तो केवल @Pattern नियमित अभिव्यक्ति मान्यताओं में लागू होगी।

/** 
* @return an additional regular expression the annotated string must match. The default is any string ('.*') 
*/ 
@OverridesAttribute(constraint = Pattern.class, name = "regexp") String regexp() default ".*"; 

/** 
* @return used in combination with {@link #regexp()} in order to specify a regular expression option 
*/ 
@OverridesAttribute(constraint = Pattern.class, name = "flags") Pattern.Flag[] flags() default { }; 

Answer 4

वास्तव में ई-मेल पते को मान्य करना वास्तव में जटिल है। यह सत्यापित करना संभव नहीं है कि एक ई-मेल पता सिंटैक्टिक रूप से सही है और एक एनोटेशन में इच्छित प्राप्तकर्ता को संबोधित करता है। @Email एनोटेशन एक उपयोगी न्यूनतम जांच है जो झूठी नकारात्मक समस्याओं की समस्या से ग्रस्त नहीं है।

सत्यापन में अगला चरण एक चुनौती के साथ एक ई-मेल भेजना चाहिए जिसे उपयोगकर्ता को यह सुनिश्चित करने के लिए पूरा करना होगा कि उपयोगकर्ता को ई-मेल पते तक पहुंच हो।

चरण 1 में कुछ झूठी सकारात्मकताओं को स्वीकार करना बेहतर है और वैध उपयोगकर्ताओं को अस्वीकार करने के लिए कुछ अमान्य ई-मेल पते पारित करने की अनुमति दें। यदि आप अतिरिक्त नियम लागू करना चाहते हैं तो आप अधिक चेक जोड़ सकते हैं, लेकिन एक वैध ई-मेल पते की आवश्यकता होने के बारे में आप वास्तव में सावधान रहें। उदाहरण के लिए आरएफसी में कुछ भी नहीं है जो निर्देश देता है कि i@nl अमान्य होगा, क्योंकि nl एक पंजीकृत देश शीर्ष-स्तरीय डोमेन है।

Answer 5

यहाँ अपाचे कॉमन्स सत्यापनकर्ता

public class CommonsEmailValidator implements ConstraintValidator<Email, String> { 

    private static final boolean ALLOW_LOCAL = false; 
    private EmailValidator realValidator = EmailValidator.getInstance(ALLOW_LOCAL); 

    @Override 
    public void initialize(Email email) { 

    } 

    @Override 
    public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) { 
     if(s == null) return true; 
     return realValidator.isValid(s); 
    } 
} 

और एनोटेशन का उपयोग कर एक javax.validation ईमेल सत्यापनकर्ता है:

@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.PARAMETER}) 
@Retention(RetentionPolicy.RUNTIME) 
@Constraint(validatedBy = {CommonsEmailValidator.class}) 
@Documented 
@ReportAsSingleViolation 
public @interface Email { 

    String message() default "{org.hibernate.validator.constraints.Email.message}"; 

    Class<?>[] groups() default {}; 

    Class<? extends Payload>[] payload() default {}; 

    @Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.PARAMETER}) 
    @Retention(RetentionPolicy.RUNTIME) 
    @Documented 
    public @interface List { 
     Email[] value(); 
    } 
} 

Answer 6

जाहिर है मैं पार्टी के लिए देर से कर रहा हूँ, फिर भी मैं इस सवाल का,

का जवाब दे रहे हूँ

हम अपने सत्यापन वर्ग में नियमित अभिव्यक्तियों के साथ @ पैटर्न एनोटेशन का उपयोग क्यों नहीं कर सकते हैं जैसे

public Class Sigunup { 

    @NotNull 
    @NotEmpty 
    @Pattern((regexp="[A-Za-z0-9._%-+]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}") 
    private String email; 

} 

यह आसान है।