前言
最近复习node相关知识，找了一个node开发个人博客的课程教学，身为一个前端开发人员全是学了许多关于后端的知识，尤其是登录部分的后端实现，由于没有借助express或koa2框架，所以整体开发下来对于登录部分逻辑有点绕，特此总结
这里登录时用户认证采用传统的session认证方式。
用户注册信息我存放到mysql数据库内，用户认证的session储存在redis数据库中
session认证方式
简单介绍一下这种认证方式
当用户登录网站时，会将用户以及密码发往服务端，服务端在数据库查询用户信息，匹配不到，返回登录失败。匹配到则返回用户登录成功，同时会返回一个cookie。
cookie为一个字符串，上面记录了用户的一些关键信息，格式为："k1=v1;k2=v2...."
客户端接收到返回信息后会将cookie储存起来，以后每当有相应域的请求时，就会自动携带cookie一起发送过去，然后服务端就可以根据发来的cookie进行用户识别（登录或未登录）
需要指出的是：
cookie要被保存在服务器上，这样才能检验用户请求中携带cookie的有效性
但这又会造成一些其他的问题：
例如：目前大型网站的服务器都不止一台，都是一个集群，不同服务器之间的cookie信息如果不能共享，就可能导致每次用户打开网站都要重新登录，这对于用户体验无疑是不佳的。
另一方面，大量用户登录，会导致服务端储存大量用户cookie信息，这也会加大对于服务器的压力。
并且cookie上需要储存能标识用户的凭证，这种信息同时也被存储在客户端，这是不安全，很容易泄露用户信息。
session认证正是为了解决这个问题，即我们将用户信息统一储存到redis服务器上，然后在该服务器上创造一个sessionId，使其与用户唯一标识信息一一对应，这样服务端在设置cookie时，就可以将sessionId传送给客户端，这就比原先cookie中的明文安全很多。
另一方面，所有服务器在进行身份认证时，都向redis服务器进行请求，这样也解决了不同服务器cookie不共享的问题。
整体思路
总结
下面对于session认证方式进行总结：
- 无论客户端请求的URL是哪个，首先都要获取cookie中的信息（也即userId）进行用户认证（认证方式即根据userID从redis服务器中取出对应的用户标识信息）
- 能够从redis中拿到用户标识信息（说明用户身份验证成功）才能访问特定的URL
- 不能从redis中拿到用户标识信息（这里我们从cookie中获取不到userId时，就再生成一个唯一的userId，用于该用户登录时的redis信息标识）（我们把该用户的userId的value值设置为{}，相当于没有从redis中获取用户信息）
