扫码登录是一个比较常用的功能。 PC客户端、 服务server 、 安卓用户之间的信息交互和扫描登录的实现方式。
server端产生一个代表二维码唯一标识的uid 及手机跳转登录网站的二维码,返回给PC 端在前端页面显示,唯一uid 将存放在redis或mysql中代表着一次登录的信息,此时Android手机扫码后,将用户的身份信息token、其他信息extinfo 及uid 发送给server端,server端将 uid 与 token + extinfo 绑定,并修改存放在redis中的uid 状态改为已扫描,(当PC端轮询查询server时,返回已扫描的前端页面显示已扫描)server端 把绑定后的信息临时token 返回 Android端,用户点击确认登录时,将临时token 返回给server端,修改server 该二维码 uid状态 为已确认,(PC端轮询时二维码状态为已确认)生成最终token,PC端 凭借token 来登录。
这个过程中 PC前端页面呈现 二维码呈现 4种状态 ,未扫描、已扫描、已确认、过期。
未扫描:pc端等待 Android用户去扫码二维码,pc端通过 轮询的方式 去请求服务端 查询此二维码的状态,通过 uid 查询 存放在redis 或者数据库中的uid 对应的状态。
列举b站上的扫码登录未扫描时的状态 response 数据 为 can t scan
将 uuid 存放在了cooike中
腾讯的放在了get url中
已扫描:pc 通过轮询 查询到uid 的状态已扫描,response 返回已扫描,但未确认 显示为 can t confirm。
已确认 :Android用户确认登录 将 临时token 发送到server,修改uid 二维码的状态,颁发正式token 用于登录到pc, 登录界面将转发到主界面。
过期:因为现在大部分 扫码登录采用的为 轮询的方式,pc 客户端浏览器 每隔 1-2s 向 server 发送请求 查询登录二维码的状态,如果很多用户都要扫码登录,那对服务器的负责分发请求的将是一个很大的压力,因此也要设置二维码的有效期限,uid 一般也存放在redis 中,也具有时效性,因此二维码进行过期,重新刷新网页将重新生成uid 二维码。
前端通过定时发送请求去请求 后端,返回数据根据返回的数据去修改 扫码的状态。
后端写一个controller,去service查询 传过来的 uid 的扫码状态,根据不同状态,返回不同的 data,如果已确认 登录 将带有token 去跳转到主页面,登录成功。
前端发送一个请求,后端采用异步的方式去处理,去阻塞请求去轮询检查 uid的状态,当uid发送变化或者过期的时候去返回响应状态,减轻后端响应多次请求的弊端,但后端需要轮询。
轮询与长轮询都是基于HTTP的,两者本身存在着缺陷:轮询需要更快的处理速度;长轮询则更要求处理并发的能力;两者都是“被动型服务器”的体现:服务器不会主动推送信息,而是在客户端发送ajax请求后进行返回的响应。而理想的模型是"在服务器端数据有了变化后,可以主动推送给客户端",这种"主动型"服务器是解决这类问题的很好的方案。Web Sockets就是这样的方案。
即时,不占用服务器资源,开发简单,总知哪都好就是“要钱”;确定:并发量小,服务真的贵,自己使用websocket轻松可以实现2万的并发
下面说下简单的实现:
4.1:进入官网:https://www.goeasy.io ;创建免费应用
轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。 优点:后端程序编写比较容易。 缺点:请求中有大半是无用,浪费带宽和服务器资源。 实例:适于小型应用。
长轮询:客户端向服务器发送Ajax请求,服务器接到请求后hold住连接,直到有新消息才返回响应信息并关闭连接,客户端处理完响应信息后再向服务器发送新的请求。 优点:在无消息的情况下不会频繁的请求,耗费资源小。 缺点:服务器hold连接会消耗资源,返回数据顺序无保证,难于管理维护。 实例:WebQQ、Hi网页版、Facebook IM。
长连接:在页面里嵌入一个隐蔵iframe,将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求,服务器端就能源源不断地往客户端输入数据。 优点:消息即时到达,不发无用请求;管理起来也相对方便。 缺点:服务器维护一个长连接会增加开销。 实例:Gmail聊天
Flash Socket:在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信,JavaScript在收到服务器端传送的信息后控制页面的显示。 优点:实现真正的即时通信,而不是伪即时。 缺点:客户端必须安装Flash插件;非HTTP协议,无法自动穿越防火墙。 实例:网络互动游戏。
轮询 长连接 长轮询说明 https://blog.csdn.net/x2145637/java/article/details/52795809
附上 模拟扫码登录的 demo java 及postman测试
为什么大多数网站登录还 采用轮询的方式呢?
https://segmentfault.com/q/1010000012892294
相关文章
HTML5中的 webSocket
https://www.runoob.com/html/html5-websocket.html
https://my.oschina.net/iyinghui/blog/1630321?from=timeline&isappinstalled=0
https://www.cnblogs.com/code-sayhi/articles/11310870.html
https://www.cnblogs.com/zhaowinter/p/5332681.html
https://www.cnblogs.com/jamaler/p/12610349.html
https://www.cnblogs.com/54chensongxia/p/12530268.html
模拟扫码登录
https://segmentfault.com/a/1190000020999524?utm_source=tag-newest
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。