登录设计

考虑的因素

跨域问题

使用传统的cookie方式登录，对于移动端的app，会存在无法使用跨域？

其实这个并不是不能跨越的壁垒，既然都是移动端了，为啥不能自己设置请求头，自己携带上，就ok了。就像curl工具，完全可以自己设置 cookie等。

token不能长期有效

需要设置一端时间内，让token失效的问题。不然泄漏了，则将会长期有效。

有效期内token失活

验证通过后，继续再验证是否失效的列表中，从redis、mysql中读取？？？

方案

方案一：token改造

这里的密码，实际上是旧的token。

请求时，携带登录信息
header token: 工号$哈希

哈希生成策略工号 + 密码 + 日期 = 产生哈希

后端验证
取工号，获取密码
同样的策略计算哈希
将生成的哈希与目标哈希进行比较。

由于加上了日期，所以，token有效期为1天。缺点，由于0点，token会瞬间失效。

另外，每次登录成功后，强制返回给用户端一端随机字符串。每次哈希的时候，再带上这种字符串。不登录，则不继续更改。

方法二：将token作为session_id使用

用户登录成功后，返回随机的session_id
session_id在时效范围内可用。自己维护在数据库或redis的存储。

用户每次请求的时候，在header中，放入token。设置token的失效时间。

由于跨域问题，手动的将session_id放到header的token字段中传输。

session_id 随机生成，而且不会长久有效。

方法三：jwt

使用jwt方式登录。

其实jwt的很多方式，在其他的登录方式中也能看到应用。

方法四：md5

使用md5简单的签名。

用户端需要传入明文的身份 + 签名。

后端，根据明文的身份，取出相关信息，按一定的方式，进行签名，校验、比较。若一致，则通过。
这实际上，又回到了方案一。只不过，所有的，都是后端计算、返回的。

缺点，一次生成，始终有效。

方法五：路由器登录模式

https://blog.csdn.net/qq_43803751/article/details/118374495

用户通过WiFi连上路由器过程中，用户端输出密码、而路由端验证，但是并没有传输密码。大致过程是：

用户要连路由器，发送请求，告诉路由，hi，哥们，我要登录了。路由器，返回一个随机的changlle给客户端。

客户端收到changelle,则将自己存储的密码，按一定的方式hash，将hash传送给路由。

路由拿到用户的hash，然后自己按同样的方式，chanllg + 密码，生成的hash跟提交的hash比较。

整个过程，完全没有见到用户提交自己的密码，抓握手包的话，也抓不到密码。想破解，难度非常的大。

缺点：系统好像就一个用户……。