最近做 APP 端 短信注册 发现移动端的跟浏览器网页还是有点区别的
一 网页： 我可以把生成的验证码 存到session 中 浏览器不关闭 我就可以在页面得到 这个验证码
调用第三方接口发短信出去 在网页接受 session 里面包含的时间为 生成的时间+你想让它失效的时间
对比 用户填完资料 注册的时间 来进行验证
二 移动端 APP 每次请求 请求玩完直接断掉了 没有 浏览器 存不到cookie 也就是那个session ID 如果想用session 还要用其他方式 传递 sessionID 我暂时做的存到数据库了 有 手机号 时间+失效时间 验证码
APP 登陆的时候 对比时间 和验证码 这点有点不爽的是 没法清理 （可以做个定时任务清理 过期的验证码）
三 延伸
按照这个道理 也可以做手机登陆 和等等 不需要服务器存东西和验证的时候 比如说购买完 我给用户发个短信 也可以调用第三方接口发送 我在网上查资料 有关移动端的这种解决方案 好像用的是 令牌 access_token
下面附上 找到的一篇博客 【 移动客户端与服务端Session那点秘密 】
众所周知，做过Web开发的小伙伴可能知道，在浏览器向服务器发一个请求，服务器端会为当前的访问者创建一个session会话，随着浏览器的关闭而会话结束。但是移动客户端咋整呢(IOS/Android啥的)。鄙人研究了一番，发现IOS/Android用原生接口发请求最大滴特点是每一次建一个会话，这样登录功能也就基本废了。登录功能的意义是将用户身份验证成功的信息存储在session里，结果每一次请求一个新的session这可不OK啊。
那么如何保证客户端的登录时创建的session在后续的接口请求中都能够行之有效的为客户端提供会话的操作，比如用户信息实体的存放，用户权限功能菜单的存放啥的。首先来科普一个概念：Cookies，不懂的自己百度，还有一个比较流行的移动端开发概念access_token，做过微信开发的应该都懂，不懂自己百度。
浏览器的工作原理也是基于cookies，这也就能解释每一次为何清空cookie后网站需要重新登录。浏览器访问服务端时，服务端在响应信息里包含了cookie信息，这个cookie里就有sessionId，这个sessionId会被浏览器自己缓存在本地cookie里，后续访问该网站的一切请求时都会自动在HTTP请求头Header里带着cookie信息。因此，服务器通过cookie里的sessionId来判断当前访问者的身份，并且从会话集合里匹配当前sessionId所对应的会话对象。
再说说另外一个概念access_token令牌，这个是自己约定的，根据开发需要。比如有这样的一个场景：用户登录请求，用户登录时，会带着用户名name和密码pwd来访问登录接口。如果服务端确认该用户是合法的，那么咱们应该由服务端生成一个access_token，保存在服务端的session会话里，并且将这个access_token返回给客户端。
OK，到这里，客户端总共获取到了两个东西，包含有sessionId的cookie和access_token，有了这两个东西，客户端后续在请求服务端的任何一个接口时，需带着access_token和Cookie即可。服务端会通过cookie识别你属于哪个session，通过access_token判断你是否合法，此次登录是否过期(服务端说了算)。上代码：
////一.登录时创建会话且返回access_token到客户端///access_token令牌作为登录状态标识HttpServletRequest req = Mvcs.getReq();HttpSession session = req.getSession(true);//创建会话//uuid作为tokenString access_token = UUID.randomUUID().toString();session.setAttribute("access_token", access_token);//out.print("access_token:"+access_token);////二.后续的接口访问中服务端过滤链逻辑/HttpServletRequest request = Mvcs.getReq();HttpSession httpSession = request.getSession(true);String rat= request.getParameter("access_token");String sat= (String)httpSession.getAttribute("access_token");if(rat!= null && rat.equals(sat)) {//如果相等,说明access_token是有效的. //放行。。。} 备注：只要你在HTTP请求头里提交了形如：Cookie:JSESSIONID=16E11471753944CF4F68A9F665E9B97F 键值对，服务器会自动根据cookie里包含的sessionId去在服务端匹配属于这个id的session并提供服务。