如果你的注册流程需要一个简单的邮箱验证功能,或许我的思考能帮到你
仅仅验证邮箱是否存在?
注册时我们需要保证用户填写的邮箱信息有效,这时我们的思路很简单,就是想办法验证邮箱是否真实存在,我去网上搜了搜,找到了我使用的第一个方法,使用rcpt to仅仅去验证邮箱是否存在
可以在点击这里稍微学习一下
https://www.activexperts.com/...
从网上找到的部分对应代码
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("123456@yahoo.com");
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;
}
不足之处的思考
但是这种方法有一些弊端:
- 我在测试的时候发现部分邮箱验证是有问题的,比如123@qq.com,这个邮箱是不存在的,但是rcpt to的返回结果是true
- 所以我们不仅需要验证邮箱是否真实存在,更需要验证这个邮箱是否是注册者本人的邮箱,如果注册者随便填一个别人的邮箱,那就乱套了
第一个问题,rcpt to确实无法保证做到100%的准确度,对于这个问题,我们可以靠其他技术来解决(JavaMailSender
),这里我参考了这篇博客
https://blog.csdn.net/herui_M...
部分常见的网站是如何进行邮箱验证的?
在思考第二个问题之前,我们不妨思考一下我们平时注册账号的网站对于邮箱验证的流程是怎么样的?在我们点击注册按钮之前,还需要点击一个验证邮箱的按钮,只有自己的邮箱收到邮件,并且自己点击邮件中的url,才会出现验证完后注册页面告诉我们的-“验证成功”
第二个问题的大致思路,后端写三个接口
sendEmail,用来发送邮件
receiveEmail,接收用户验证信息临时存储到缓存中,
checkEmail,查询缓存,验证Email是否已被验证
初期的简单流程
整体的流程是这样的:
- 前端验证邮箱格式后,请求send接口
- 后端send接口发送验证邮件(邮件中的url中应该携带email信息,为了避免泄露信息,可以先对email的信息加密在进行拼接)
- 用户收到邮件,点击链接访问
- 前端拿到加密过的email信息,去请求receive接口
- receive接口对加密的email进行解密,然后判断是否为邮箱格式,再存入Redis缓存中
- 前端访问check接口,查询Redis缓存中是否有email信息
用户之间的验证冲突
这样看似已经差不多可以了,但是还有一种情况——a注册了b的邮箱
假设有a,b两个用户,同时注册,a填写了b的email信息,b也填写了b的email信息,显然发送验证email信息的时候,这个邮件只有b真实能收到,b点了验证链接,a的流程却抢先一步去查询了Redis中email是否被验证,我们知道这个email是b所属且b本人验证的,而在这个过程中a却反客为主,将邮箱占为己有,所以这里的问题就是,我们如何保证,a申请的邮箱一定是a本人点击确认的,即前端申请email的人和缓存中点击email确认的人是一个人
进一步思考后的整体流程
这个问题的解决方法就是用一个唯一标识符UUID来解决,我们对之前的流程重新思考一下
- 前端验证邮箱格式后,请求send接口
- 后端send接口发送邮件,邮件中的url应该包含加密的email信息和UUID,并且应该把UUID返回给前端
- 用户收到send接口发来的邮件,点击链接访问
- 前端收到了加密的email信息和UUID信息,加密的email信息不做处理,对此时收到的UUID和请求send接口时收到的UUID进行比较,防止恶意访问(这也是为什么第二步send接口应该返回给前端UUID的原因),验证通过后携带加密的email信息和UUID去请求receive接口
- receive接口收到信息后,对加密的email信息解密和格式验证,然后以键值对的形式将email-UUID存入Redis缓存中
- 前端访问check接口,携带email和UUID查询缓存中是否存在,然后再去申请注册
思考过程难免会有疏漏,欢迎指正