token问题

Question

我想问在http请求中，怎么才能确保是用户本人，我看了一些博客，说可以用session来解决，就是比较耗费服务器性能，但在请求参数中放用户ID又不安全，而且也容易被篡改信息，有人说要用token，但是token又怎么传输呢？放在cookie中吗？那这样是不是每次请求，后端程序员不是每个方法都要核实token，那样的话后端代码不会很臃肿吗？请各位大牛给个解决方案。

Answer 1

如果使用token一般的做法就是登陆完了之后把服务器返回的token存在前端请求头里,每次请求都带有该token,后端写拦截器统一的拦截器

Answer 2

用拦截器,存redis

Answer 3

token验证通过后要怎么获取当前用户信息呢？难道每个方法前都要查询数据库的用户信息吗？能详细解释一下吗？

Answer 4

token验证通过后要怎么获取当前用户信息呢？难道每个方法前都要查询数据库的用户信息吗？能详细解释一下吗？
你在token中可以存一个用户对象

Answer 5

token验证通过后要怎么获取当前用户信息呢？难道每个方法前都要查询数据库的用户信息吗？能详细解释一下吗？
你在token中可以存一个用户对象
那token不是一个简单的字符串吗？我感觉存对象的话有点信息不安全的感觉

Answer 6

可以存redis的，每一个token对应一个用户

Answer 7

怎样的获取用户信息呢？每个方法里都查询redis吗？这样感觉代码很臃肿啊！有什么方法能获取用户信息给全局使用吗？

Answer 8

token验证通过后要怎么获取当前用户信息呢？难道每个方法前都要查询数据库的用户信息吗？能详细解释一下吗？
你在token中可以存一个用户对象
那token不是一个简单的字符串吗？我感觉存对象的话有点信息不安全的感觉
不要把对象全部放进去,抽取一部分不敏感的属性做一个dto类,使用密钥+动态加密.
对象转字符串的话网上搜一下很多工具的,到时候解密再反序列化也方便

Answer 9

对呀，过滤器里获取了用户信息，但是业务里的service层还是没有用户信息啊，这样的话service层不是每个方法都要再获取一次用户信息吗？过滤器或者拦截器里的对象怎么在service层里使用呢？

Answer 10

哦哦，明白了，你不只是鉴权，还要用户信息是么，那不需要拦截器了，你可以封装一个获取用户信息的工具类，在这个工具类里验证token并且返回token对应的用户信息，接口中调用这个方法就行

Answer 11

这样的话需要用户信息的接口调一下方法就行，也就一行，你非要全局好像就只能用session了

Answer 12

问一下 能不能在过滤器查询到用户信息的时候，通过注解给他注入到service层呢？
比如：
在xxxService.java中用
@TokenUser
User user

Answer 13

问一下 能不能在过滤器查询到用户信息的时候，通过注解给他注入到service层呢？
比如：
在xxxService.java中用
@TokenUser
User user
好像不行的，注解就是用来处理业务的，整个项目没有一个全局的东西，除了数据库和session

Answer 14

我觉得用session或者redis可以了，那性能没多大损耗的

Answer 15

我其实知道核实token后查到用户信息可以用session.setAttribute(“tokenUser”, user);然后在xxxController的方法里session.getAttribute(“tokenUser”);然后传参给xxxService里的业务方法，实现具体业务
但每个方法都来这么一下，心里就是有点不舒服
所以想知道有没有什么方法可以直接核实token获取用户信息后能在业务层使用
不管是 过滤器 拦截器 aop切点 还是注解的方式
大佬们可以写一篇博客为我解惑吗？

Answer 16

生成后的token可以放在请求的头中，每次请求的时候都携带这样就不用在后台去循环cookie去判断。登录的用户信息可以转换成json格式的数据，存放在redis中，在每次请求都去redis去判断

Answer 17

按你的需求
可能登录接口写个加密文件来加密用户信息返回给前端
请求其他接口前端带这个加密参数过来就好了 后端解密
这样更方便些 
加解密文件自己制定规则
不用考虑用token

Answer 18

注入的那个需求个人感觉没戏 或者说意义不大
首先 你怎么在拦截器层就知道程序后面会走哪些service类？你怎么拿到后面会运行的那些个service对象？另外 这些一般是单实例复用 这就涉及到并发中经典的火车票问题  如果不做锁就会出现拿错用户的情况 如果做了锁 那就没有性能了service层处理请求成串行了

Answer 19

token可以是一个加密的字符串,你可以在后台解密出来,然后解密出来的信息,可以是少量的用户信息,比如用户id,名称,其他的等等. 又或者说,你每次登陆都可以把用户信息 存到redis, 然后token作为key, 你需要的时候,去redis里面取 对应的信息

Answer 20

对呀，过滤器里获取了用户信息，但是业务里的service层还是没有用户信息啊，这样的话service层不是每个方法都要再获取一次用户信息吗？过滤器或者拦截器里的对象怎么在service层里使用呢？在拦截器里根据token得到use之后放在threadlocal中。然后再service中yong q

Answer 21

如果真的对安全要求这么高，那为什么不用https呢？这样把token放head里也是安全的了

Answer 22

单体服务：
可以在登录成功之后生成一个token，前端将token保存在本地，请求的时候放在request headers中，后端只需要在拦截器中做统一处理，不需要在业务中做判断，
分布式服务：
前端的处理方式还是不变，后端的校验交给网关统一处理，比如zuul、gateway等等。
需要注意的是在解决跨域问题的时候，在允许请求头参数的时候把你的token字段加上，否则会一直处于跨域状态
  

Answer 23

ThreadLocal大概是你想要的东西,在拦截器中获取用户信息,丢到ThreadLocal里,当前线程随时都可以拿到用户信息,你只需要一个静态方法还有token和session没有本质的区别

Answer 24

前端没有绝对安全的，后端返回一个会过期的token作为前端获取数据的验证方式，相对来说已经很合理了

Answer 25

token作为redis的key值，用户信息作为value，写一个工具类TokenUtil，里面有封装方法，createToken,distoryToken,verifyToken,getCurrentUser,refrushToken,在用户登录成功的时候，将token存储redis同时存储用户信息，在用户访问接口的时候，必须带上token，用verifyToken来验证，因为每次都需要验证，所以放入拦截器或者过滤器，在需要获取用户信息的地方，用getCurrentUser来从redis获取就行了，不建议用session，因为http是无状态协议，如果用session就会出现每请求一次就出现一个session，这在api开发中是严格杜绝的，因为服务器根本承担不起。

Answer 26

在第一次账号密码登录之后，服务端返回给客户端一段字符串，这个就是token，这个字符串可以是redis的key值。然后每次请求都将token放在请求头里，服务端拦截器或者过滤器统一拦截，验证登录，如果找不到相应信息，就提示登录失效重新登录，如果有就放行。然后在控制层获取用户信息，你可以写一个专门的工具类去获取，因为并不是所有的接口都必须要获取用户信息的，但是一定会验证登录。

Answer 27

我觉得应该就用basic验证就可以吧，或者自己设计一套，token超时什么乱七八糟的

Answer 28

session绑定随机生成的token存入表单隐藏域。过滤器过滤Cookie的session和token，拦截非法访问。

Answer 29

你安全度要求那么高，性能又要那么高.......又想马儿跑得快，又想马儿吃得少。上面的回复都能解决绝大部分实际问题了，token脱敏加密、redis存信息（redis本身就是用的内存，性能很高的，心里放宽点）、统一拦截器减少查询次数。这只能是一个均衡的点，没法两全的。而且其实这样做安全性和性能都不低了。双十一要来了，你买东西的时候，没觉得等着急吧，没爆出客户信息被黑了吧。或者12306，也没啥大事吧，性能...现在也比以前有很大提升了。

Answer 30

我不知道有没有理解对你的意思，你意思是用户每用一次操作都要判断是不是这个用户在操作，但是这个不是后台的事情，登陆了以后你的登录信息就保存在前端了，这是前端的事情，后台提供登录接口，返回一个token就行了