How to verify email address when registering?

Time:2020-10-31

If your registration process needs a simple email verification function, maybe my thinking can help you

Does the mailbox only exist?
When registering, we need to ensure that the email information filled in by users is valid. At this time, our idea is very simple, that is, we try to find out whether the mailbox really exists. I searched the Internet and found the first method I used. I used RCPT to verify whether the mailbox exists

You can learn a little bit here
https://www.activexperts.com/…

Some corresponding codes found on the Internet

    public Response CheckEmailValidity(@RequestParam (value="email") String email) {

        String host = "";
        String hostName = email.split("@")[1];
        Record[] result = null;
        SMTPClient client = new SMTPClient();
        Response response = new Response();

        try {
            // find MX records
            Lookup lookup = new Lookup(hostName, Type.MX);
            lookup.run();
            if (lookup.getResult() != Lookup.SUCCESSFUL) {
                response.setCode(ResponseCode.FAIL);
                response.setMessage("The email is not exist");
                logger.debug(response.getMessage());
                return response;
            } else {
                result = lookup.getAnswers();
            }

            // connect to email server
            for (int i = 0; i < result.length; i++) {
                host = result[i].getAdditionalName().toString();
                client.connect(host);
                if (SMTPReply.isPositiveCompletion(client.getReplyCode())) {
                    break;
                }
                client.disconnect();
            }

            client.login("dashanju");
            client.setSender("[email protected]");
            client.addRecipient(email);
            if (250 == client.getReplyCode()) {
                response.setCode(ResponseCode.SUCCESS);
                response.setMessage("The email is exist");
            }else{
                response.setCode(ResponseCode.FAIL);
                response.setMessage("The email is not exist");
                logger.debug(response.getMessage());
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                client.disconnect();
            } catch (IOException e) {
            }
        }
        return response;
    }

Thinking about the shortcomings
But this method has some disadvantages

  • During the test, I found that there were problems with some mailbox verification, such as [email protected] The mailbox does not exist, but the returned result of RCPT TO is true
  • We not only need to verify whether the mailbox really exists, but also need to verify whether the mailbox is the registrant’s own mailbox. If the registrant fills in someone else’s mailbox at will, it will be a mess

The first problem, RCPT TO, can not guarantee 100% accuracy. For this problem, we can rely on other technologies to solve it(JavaMailSender)Here I refer to this blog
https://blog.csdn.net/herui_M…

How do some common websites do email verification?
Before thinking about the second question, we might as well think about how the email verification process of the website where we usually register accounts? Before we click the registration button, we also need to click a button to verify the mailbox. Only when our mailbox receives the email and clicks the URL in the email, will the registration page tell us that “verification succeeded” will appear

The second problem is the general idea of writing three interfaces on the back end
Sendemail, which is used to send e-mail
Receiveemail, which receives the user authentication information and stores it in the cache temporarily,
Check email to query the cache to verify whether the email has been verified
Simple process at the beginning
The overall process is as follows:

  1. After verifying the mailbox format, the front end requests the send interface
  2. The back-end send interface sends verification mail (email information should be carried in the URL of the email. In order to avoid information disclosure, the email information can be encrypted and spliced first)
  3. Users receive the email and click the link to visit
  4. The front end gets the encrypted email information and requests the receive interface
  5. The receive interface decrypts the encrypted email, then determines whether it is in mailbox format, and then stores it in redis cache
  6. The front end accesses the check interface to query whether there is email information in redis cache

Authentication conflicts between users
This seems to be almost OK, but there is another situation
Suppose there is a, Two users B register at the same time. A fills in the email information of B, and B also fills in the email information of B. obviously, when sending the verification email information, only B can receive this email. B clicks the verification link, but a preemptively queries whether the email in redis is verified. We know that this email belongs to B and B has verified it. However, in this process, a turns its back on the customer and gives priority to it E-mail accounts for our own, so the problem here is, how can we ensure that the mailbox a applies for must be confirmed by a himself, that is, the person who applies for email at the front end and the person who clicks email confirmation in the cache are the same person
Overall process after further consideration
The solution to this problem is to use a unique identifier UUID. Let’s rethink the previous process

  1. After verifying the mailbox format, the front end requests the send interface
  2. The back-end send interface sends mail. The URL in the email should contain encrypted email information and UUID, and the UUID should be returned to the front end
  3. After receiving the email from send interface, users can click the link to visit
  4. The front end receives encrypted email information and UUID information, and the encrypted email information is not processed. The UUID received at this time is compared with the UUID received when the send interface is requested to prevent malicious access (this is why the send interface should return to the front-end UUID in the second step). After verification, the encrypted email information and UUID are carried to request the receive interface
  5. After receiving the message, the receive interface decrypts and verifies the encrypted email information, and then stores the email UUID in redis cache in the form of key value pairs
  6. The front end accesses the check interface and carries email and UUID to query whether the cache exists

There will inevitably be omissions in the process of thinking. Please forgive me

Recommended Today

Async await async download asynchronous code lock asynchronous cache

Async await async download asynchronous code lock asynchronous cache FTP asynchronous download code: /// ///Download files asynchronously /// ///FTP path ///User name ///Password ///File relative path public static async Task DownloadFileAsync(string ftpPath, string ftpUserId, string ftpPassword, string relativeFilePath) { FtpWebRequest request = null; try { LogTimeUtil log = new LogTimeUtil(); request = (FtpWebRequest)WebRequest.Create(new Uri(Path.Combine(ftpPath, relativeFilePath).Replace(“\\”, […]