境外网站服务器,住房和建设局官网,管理系统中计算机应用实践考试,增城网站开发新开发一个应用首先要考虑的就是登录怎么去做#xff0c;登录本身就是判断一下输入的用户名和密码与系统存储的是否一致#xff0c;但因为Http是无状态协议#xff0c;用户请求其它接口时是怎么判断该用户已经登录了呢#xff1f;下面聊一个三种实现方案。
一、传统sessio…新开发一个应用首先要考虑的就是登录怎么去做登录本身就是判断一下输入的用户名和密码与系统存储的是否一致但因为Http是无状态协议用户请求其它接口时是怎么判断该用户已经登录了呢下面聊一个三种实现方案。
一、传统session方案
这种方案在以前前后端架构不分离的时候采用的基于客户端Cookie和服务端Session来做基本流程如下
1、用户登录成功后查询数据库取出用户信息放到Session中。
2、服务端往客户端浏览器写CookieCookie里存放加密的用户名一般用3DES搞搞就可以如果是非交易网站甚至有直接明文或只做一下Base64.
3、用户请求接口时浏览器会把Cookie发送给服务端服务端拿到这个Cookie解析出用户名然后根据用户名获取Session里用户对象信息.
4、如果应用部署在多台服务器需要做Session同步这里一般有两种做法一种是通过容器Tomcat本身进行Session复制但存在一个问题当用户量大的时候每台服务器重复存放大量的Session对象会占用大量的内存另外一种做法是写一个拦截器用户在A机器登录后会在当前服务器生成Session然后用户下一个请求被路由到机器B这时需要做Session的恢复解析出Cookie中用户名查找到用户数据然后放到Session里去该用户下次请求如果还是路由到该台机器就不用再查数据库了。
缺点
1、Session存在内存中用户多会占用大量应用服务器的内存.
2、Cookie安全性如果Cookie被截获很容易造成跨站请求伪造脚本攻击.
3、前后端分离的应用无法使用Cookie
PS:十几年前跟着大牛做过这个事情在整理文章时花了点时间才慢慢回忆起来。
二、tokenredis方案
当前公司的收银系统采用的就是该方案具体实现流程如下
1、用户登录成功后生成一个TokenToken的生成依赖于Linux系统的urandom然后将token和查询出来的用户对象数据存到redis中 token做为keyvalue存用户对象并将token返回给客户端redis设置过期时间12小时。
cat /dev/urandom |od -x | tr -d | head -n 1
2、客户端拿到Token存到localStorage里然后写一个通用的请求拦截,在每次请求时http头加上token值。 3、服务端写一个注解NeedLogin需要登录的接口加上该注解.
4、服务端写一个拦截器判断请求的方法上有没有加NeedLogin注解如果没有注解则返回如果有注解则从Http请求头中把Token拿出来判断该Token是否存在存在则认为是处于登录状态的。
5、接口调用时需要根据Token值从Redis中获取用户对象数据
优缺点服务端可以主动让Token失效但用户信息存在Redis占用一定空间并且需要一次redis查找(PS好像不不算什么缺点)属于中心化方案。
三、Jwt方式
当前公司在线窗帘定制网站采用的是该方案Jwt即Json Web Token实现流程和Token方案基本一样区别在于用户信息保存在Jwt中客户端每次请求都会把Jwt带过来服务端从Jwt解析出用户对象数据。
Jwt的组成 header声明类型及签名算法做Base64。 playload: 包括注册的声明签发时间/过期时间/面向的用户、公共和私有声明内容也仅只做Base64编码. signbase64header)base64(playload)secret 优缺点该方案跨语言、另外payload可以存放非敏感用户数据以减少数据库或缓存查询、它不需要服务端保存会话信息、应用易于扩展、但服务端无法主动让Jwt失效因为数据安全性尽可能使用https协议。
