今年是9102年了,应该没有还在用 userId
来鉴权了吧,也应该很少人使用 cookie
来保持会话了吧?而现在更常用的是 Authorization
,
简略的讲一讲Authorization,如果要深入了解的话请看底部的参考文章链接。Authorization的认证方式在我接触中有两种
HTTP基本认证,在请求的时候加上以下请求头:
Authorization : basic base64encode(username+“:”+password))
将用户名和密码用英文冒号(:)拼接起来,并进行一次Base64编码。服务端拿到basic码,然后自己查询相关信息再按照 base64encode(username+":"+password))
的方式得出当前用户的basic进行对比。
授权完成后会返回类似下面的数据结构:
{ "token_type": "Bearer", "access_token": "xxxxx", "refresh_token": "xxxxx" }
而其中的 refresh_token
的作用是在 access_token
失效的时候进行重新刷新传入的参数,具体怎么传要看各自项目的实现方式。
access_token
就是我们的认证令牌。token_type是令牌的类型,而我现在使用到的只有 bearer
,其它类型未碰到,希望各位看官能补充一下。
在使用的时候需要加上以下请求头:
Authorization : token_type access_token
也就是这样:
Authorization: Bearer xxxxx
authenticator
是在创建 OkHttpClient
的时候能够设置的一个方法,接收的是一个 okhttp3.Authenticator
的interface,默认不设置的话是一个 NONE
的空实现,而回调的地方是在 okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest()
相关代码也比较简单,在 okhttp3.Authenticator
的注释上面也写有简单的例子,核心代码就以下几行:
private Authenticator authorization = new Authenticator() { @Override public Request authenticate(Route route, Response response) throws IOException { //-----------核心代码------- // 这里抛出的错误会直接回调 onError // 这里发起的请求是同步的,刷新完成token后再增加到header中 // String token = refreshToken(); String token = Credentials.basic("userName", "password", Charset.forName("UTF-8")); return response.request() .newBuilder() .header("Authorization", token) .build(); //-----------核心代码------- } };
以上就是主要代码,其中演示的是 basic
方式的认证模式, bearer
方式的没实现,其实也只是 refreshToken()
中发起一个 同步请求
去刷新一下 token
并保存,后面的步骤都是一样的。
创建OkHttpClient调用,当然,也可以直接写匿名内部类的实现,都是可以的。
retrofit = new Retrofit.Builder() .client(new OkHttpClient.Builder() .authenticator(authorization)// 增加重试 .addInterceptor(getHttpLoggingInterceptor()) .build()) .baseUrl("https://api.github.com/") .addCallAdapterFactory(RxJava2CallAdapterFactory.create()) .addConverterFactory(GsonConverterFactory.create()) .build();
为了演示方便看到结果,我在 Authenticator
的实现类中增加了一些回调主线程的方法,具体看一下源码即可,对于主要结果没什么影响。
使用官方提供的 Authenticator
有一个很明显的问题,那就是会占用 重试
,像示例中,我并没有传入一个正确的 token
,就导致一直在回调 Authenticator
,直到达到了最大重试次数为止。而往往需求是token失效以后选择重试一次,成功了继续请求,再次失败则提示登录,所以这个方法使用得不多。
上面 okhttp3.Authenticator
的实现方式其实是在 RetryAndFollowUpInterceptor
中判断和回调的,由此,可以自定义一个 Interceptor
,由开发者来自行判断和跳转。
详细代码如下:
Interceptor mAuthenticatorInterceptor = new Interceptor() { @Override public Response intercept(Chain chain) throws IOException { // 获取请求 Request request = chain.request(); // 获取响应 Response response = chain.proceed(request); // 在这里判断是不是是token失效 // 当然,判断条件不会这么简单,会有更多的判断条件的 if (response.code() == 401) { // 这里应该调用自己的刷新token的接口 // 这里发起的请求是同步的,刷新完成token后再增加到header中 // 这里抛出的错误会直接回调 onError // String token = refreshToken(); String token = Credentials.basic("userName", "password", Charset.forName("UTF-8")); // 创建新的请求,并增加header Request retryRequest = chain.request() .newBuilder() .header("Authorization", token) .build(); // 再次发起请求 return chain.proceed(retryRequest); } return response; } }
和方法一相同,在创建 HttpClient
的时候 addInterceptor(mAuthenticatorInterceptor)
,将我们自己的拦截器加入进行即可。
从演示中可以看出,在第一次返回 401
的时候,进行了一次token的获取,并且再次进行了请求,圆满符合我们的预期,只重试一次。
可能会有疑问:为什么使用 Interceptor
就能达到我们预期的效果? Interceptor
到底是如何工作的?
首先 Interceptor
添加是有先后顺序的,首先添加的是我们设置的 Interceptor
,然后添加的才是 okhttp
的 Interceptor
。如源码中:
总的来说, okhttp
的实现方式就是通过 Interceptor
来组成一个一个的 chian
来实现的。每个 Interceptor
里面的 intercept()
方法内部都会调用 Chain.proceed()
方法,将请求交给下一个 Interceptor
,由此类推,一直到最后一个 Interceptor
请求完成。
需要注意的是 proceed
是同步的,也就是调用 proceed
方法之后需要等等下一个 Interceptor
进行处理,当最后一个 Interceptor
请求到数据,经过自己的处理之后,再往上返回 Response
,直到第一个 Interceptor
为止,返回数据。主要关系如下图:
这些所有的 Interceptor
里面的 proceed
都是调用了一次,那么我们增加一个 Interceptor
,等到 proceed
返回了 Response
之后,对 Response
进行判断,如果是认证失败,我们则刷新一下token,重新创建Request,再调用一次 proceed
方法。如果再失败了,就不会再回调到当前的 Interceptor
,如下图:
一个痴心妄想想成为一个全屏(栈)工程师的程序猿。
来来,关注一下吧!