标签:return RequestContext ctx 62 Token Override Zuul public
服务之间接口调用的安全认证是通过 Feign 的请求拦截器统一在请求头中添加 Token 信息,实现认证调用。还有一种调用方式也是需要进行认证,就是我们的 API 网关转发到具体的服务,这时候就不能采用 Feign 拦截器的方式进行 Token 的传递。
在 Zuul 中我们可以用 pre 过滤器来做这件事情,在路由之前将 Token 信息添加到请求头中,然后将请求头转发到具体的服务上。
通过 Zuul 的 pre 过滤器进行 Token 的设置,代码如下所示。
/** * 调用服务前添加认证请求头过滤器 **/ public class AuthHeaderFilter extends ZuulFilter { public AuthHeaderFilter() { super(); } @Override public boolean shouldFilter() { RequestContext ctx = RequestContext.getCurrentContext(); Object success = ctx.get("isSuccess"); return success == null ? true : Boolean.parseBoolean(success.toString()); } @Override public String filterType() { return "pre"; } @Override public int filterOrder() { return 5; } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); ctx.addZuulRequestHeader("Authorization", System.getProperty("fangjia.auth.token")); return null; } }
Token 的刷新机制和之前讲的一模一样,还是用那个定时器,直接复制过去即可,但是必须依赖申请 Token 的 Feign 客户端的定义。
标签:return,RequestContext,ctx,62,Token,Override,Zuul,public 来源: https://www.cnblogs.com/jrkl/p/14444965.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。