web登录浅析

web登录浅析

HTTP协议是无状态的

1.是否一定需要登录注册

是否需要注册和登录的关键取决于产品形态。

　　如果用户注册登录对于用户需求、产品功能、商业模式本身带不来任何价值的话，就没必要设计这样的功能。比如一些实用工具类的产品：在线格式化、翻译、无社交属性的天气预报等等。

　　其它像强社交需求的产品(微信)、涉及到较多用户财产安全的产品(支付宝)、用户对信息使用比较关注的产品(邮箱)等，都需要账户体系的支持，自然也就需要注册和登录。

总结：系统需要知道是谁在操作那么就需要登录，不需要知道是谁就不需要登录。

注：记录用户身份为什么需要登录：http协议一种无状态的协议之后该客户端再次向该服务区发送请求后，服务器端并不能知道这两个请求是否是同一个浏览器或用户发出来的。所以作为web服务器必须能够采用某种方式来唯一识别同一个用户，并记录该用户的状态。而这同一个客户端与服务器端的在一段时间内的多次交互，我们就可以称该客户端为该服务器端的一个客户端会话窗口，有了会话窗口，我们就能确定哪个请求是哪个用户发出的了，从而可以实现会话跟踪，并记录用户的行为。

2.注册和登录的意义

1.从用户的角度而言，注册和登录功能是：

　　 a)个体身份的映射，代表自己独立的存在;

　　 b)保存用户自身使用APP的行为轨迹(收藏、点赞等)

　　 c)产出带用户个人标签的UGC内容(评论、发文、投稿等)

　　 d)与平台的其他用户建立联系

　　 e)在多设备、平台上同步账户数据

2.从产品的角度而言，注册和登录功能可以：

　　 a)收集用户信息，标签化

　　 b)生成用户画像，为精细化运营做准备

　　 c)为用户提供个性化服务

　　 d)收入转化(通过销售用户信息)

3.会话机制（登录的机制）

会话机制有两种 Cookie机制、Session机制 。 （token机制 特殊的机制 实际上是基于Session）

1.cookie机制

当一个浏览器访问某web服务器时，web服务器会调用HttpServletResponse的addCookie()方法，在响应头中添加一个名叫Set-Cookie的响应字段用于将Cookie返回给浏览器，当浏览器第二次访问该web服务器时会自动的将该cookie回传给服务器，来实现用户状态跟踪。

缺点：cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗

2.session机制

服务器第一次接收到请求时，开辟了一块Session空间（创建了Session对象），同时生成一个Session id，并通过响应头的Set-Cookie：“JSESSIONID=XXXXXXX”命令，向客户端发送要求设置cookie的响应； 客户端收到响应后，在本机客户端设置了一个JSESSIONID=XXXXXXX的cookie信息。

接下来客户端每次向同一个网站发送请求时，请求头都会带上该cookie信息（包含Session id）； 然后，服务器通过读取请求头中的Cookie信息，获取名称为JSESSIONID的值，得到此次请求的Session id；

缺点：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面。集群部署session同步的问题

{JSESSIONID：‘cookie’}

3.token机制（特殊，不是web规范）

jwt (JSON Web Token)就是一种token登录的一种具体实现方式

方案 1 ：我发给你一张不加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人

方案 2：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。

方案 3 ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。

4.登录扩展

1.第三方登录

一、注册应用（最繁琐不可控）

微信开放平台注册开者账号 并添加应用 微信开放平台

二、按照文档生成二维码

准备工作 | 微信开放文档

三、按照项目需求绑定账号等

参考：微信开放平台PC端扫码登录功能个人总结 - 还行吗年轻人 - 博客园

2.sso登录

一、是什么

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一

SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统

例子

 

百度文库、百度地图、百度视频都属于百度旗下，当用户登录百度文库后，再打开百度地图，系统便自动帮用户登录了百度地图，这种现象就属于单点登录

二、如何实现

同域名下的单点登录

cookie的domin属性设置为当前域的父域，并且父域的cookie会被子域所共享。path属性默认为web应用的上下文路径

利用 Cookie 的这个特点，没错，我们只需要将Cookie的domain属性设置为父域的域名（主域名），同时将 Cookie的path属性设置为根路径，将 Session ID（或 Token）保存到父域中。这样所有的子域应用就都可以访问到这个Cookie

不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com这个主域名之下，那么它们就可以通过这种方式来实现单点登录

不同域名下的单点登录(一) —— 认证中心

如果是不同域的情况下，Cookie是不共享的，这里我们可以部署一个认证中心，用于专门处理登录请求的独立的 Web服务

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 token 写入 Cookie（注意这个 Cookie是认证中心的，应用系统是访问不到的）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心

由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了

如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录

如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL，并在跳转前生成一个 Token，拼接在目标URL 的后面，回传给目标应用系统

应用系统拿到 Token之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token写入Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了

此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法

不同域名下的单点登录(二) —— iframe+postMessage() 传值

可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将LocalStorage的数据传递给服务端

这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID（或 Token）放在响应体中传递给前端

单点登录完全可以在前端实现。前端拿到 Session ID（或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中

*前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取Token并在请求中携带，这样就实现了同一份Token 被多个域所共享

不同域名下的单点登录(三) —— 跨域设置cookie

通过设置 axios.defaults.withCredentials = true 可以跨域名设置cookie 注意core不能设置*