十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
由身份或持有的令牌确认享有的权限,登录过程实质上的目的也是为了确认权限。
创新互联-专业网站定制、快速模板网站建设、高性价比修文网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式修文网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖修文地区。费用合理售后完善,十年实体公司更值得信赖。
Cookie是客户端给服务器用的,setCookie是服务器给客户端用的。cookie由服务器处理,客户端负责存储
客户端发送cookie:账户和密码
服务端收到后确认登录setCookie:sessionID=1,记下sessionID
客户端收到sessionID后记录,以后请求服务端带上对比记录下sessionID,说明已经登录
会话管理:登录状态,购物车
个性化:用户偏好,主题
Tracking:分析用户行为
XXS:跨脚本攻击,及使用JavaScript拿到浏览器的cookie之后,发送到自己的网站,以这种方式来盗用用户Cookie。Server在发送Cookie时,敏感的Cookie加上HttpOnly,这样Cookie只能用于http请求,不能被JavaScript调用
XSRF:跨站请求伪造。Referer 从哪个网站跳转过来
两种方式:Basic和Bearer
首先第三方网站向授权网站申请第三方授权合作,拿到授权方颁发的client_id和client_secret(一般都是appid+appkey的方式)。
在这就过程中申请的client_secret是服务器持有的,安全起见不能给客户端,用服务端去和授权方获取用户信息,再传给客户端,包括④,⑤的请求过程也是需要加密的。这才是标准的授权过程。
有了access_token之后,就可以向授权方发送请求来获取用户信息
步骤分析就是上面的内容,这里把第4,6,8请求的参数分析一下
第④步参数:
response_type:指授权类型,必选,这里填固定值‘code’
client_id:指客户端id,必选,这里填在平台报备时获取的appid
redirect_uri:指重定向URI,可选
scope:指申请的权限范围,可选
state:指客户端当前状态,可选,若填了,则认证服务器会原样返回该值
第⑥步参数:
grant_type:指使用哪种授权模式,必选,这里填固定值‘authorization_code’
code:指从第⑤步获取的code,必选
redirect_uri:指重定向URI,必选,这个值需要和第④步中的redirect_uri保持一致
client_id:指客户端id,必选,这里填在平台报备时获取的appid
client_secret:指客户端密钥,必选,这里填在平台报备时获取的appkey
第⑧步参数:
access_token:指访问令牌,必选,这里填第⑦步获取的access_token
token_type:指令牌类型,必选,大小写不敏感,bearer类型 / mac类型
expires_in:指过期时间,单位秒,当其他地方已设置过期时间,此处可省略该参数
refresh_token:指更新令牌,可选,用即将过期token换取新token
scope:指权限范围,可选,第④步中若已申请过某权限,此处可省略该参数
我们在上面的第八步中会有refresh_token的参数,这个在实际操作中也比较常见
有时候我们在自己的项目中,将登陆和授权设计成类似OAuth2的过程,不过去掉Authorization code。登陆成功返回access_token,然后客户端再请求时,带上access_token。
我们常常会说到TCP/IP,那到底是什么呢。这就需要讲到网络分层模型。TCP在传输层,IP在网络层。那为什么需要分层?因为网络不稳定,导致需要重传的问题。为了提高传输效率我们就需要分块,在传输层中就会进行分块。TCP还有两个重要的内容就是三次握手,四次分手。
HTTPS 协议是由 HTTP 加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议,主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密,实现互联网传输安全保护
1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表(所使用的加密算法及密钥长度),客户端随机数,hash算法。
2.服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件,服务端随机数。服务器的加密组件内容是从接收到客户端加密组件内筛选出来的。
3.之后服务器发送Certificate报文。报文中包含公开密钥证书。一般实际有三层证书嵌套,其实像下面图二直接用根证书机构签名也是可以的,但是一般根证书机构比较忙,需要类似中介的证书机构来帮助。
4.最后服务器发送Server Hello Done报文通知客户端,最初阶段的SSL握手协商部分结束。
5.SSL第一次握手结束后,客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
6.接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器,在此报文之后的通信会采用Pre-master secret密钥加密。
7.客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密报文作为判定标准。
8.服务器同样发送Change Cipher Spec报文。
9.服务器同样发送Finished报文。
10.服务器和客户端的Finished报文交换完毕之后,SSL连接就算建立完成。当然,通信会受到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP响应。
11.应用层协议通信,即发送HTTP响应。
12.最后由客户端断开连接。断开连接时,发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。
利用客户端随机数,服务端随机数,per-master secret随机数生成master secret,再生成客户端加密密钥,服务端加密密钥,客户端MAC secert,服务端MAC secert。MAC secert用于做报文摘要,这样能够查知报文是否遭到篡改,从而保护报文的完整性。
Android网络请求知识(一)HTTP基础概念
Android网络请求知识(二)对称和非对称加密、数字签名,Hash,Base64编码
Android网络请求知识(三)授权,TCP/IP,HTTPS建立过程
手机版本升级到9.0后,发现App一直请求网络失败,特奇怪...以为是手机出毛病了,后来发现原来是android 9.0系统已经默认不支持http请求了,这个可以让后台改成https就行,不过我们还是没解决我们移动端的问题。目前有两个方法处理:
1.把targetSdkVersion 改成27或者以下
2.在res目录添加一个xml文件夹和network_security_config.xml:
xml内容是:
然后再在AndroidManifest.xml的application里加入
这样就行了。
OkHttp是一套处理 HTTP 网络请求的依赖库,由 Square 公司设计研发并开源,目前可以在 Java 和 Kotlin 中使用。对于 Android App 来说,OkHttp 现在几乎已经占据了所有的网络请求操作,Retrofit + OkHttp实现网络请求似乎成了一种标配。因此它也是每一个 Android 开发工程师的必备技能,了解其内部实现原理可以更好地进行功能扩展、封装以及优化。
OkHttp的高效性体现在:
第一步:创建OkHttpClient,创建OkHttpClient有两种方式:
OkHttpClient提供了丰富的配置方法,例如添加拦截器、指定连接池、设置请求超时等等。
第二步:创建请求
使用Request.Builder() 构建Request实例
第三步:发起网络请求
OkHttp支持同步和异步两种请求方式
OkHttp的使用方法非常简单,三步操作就可以发起一个简单的同步或异步请求。我们也可以很轻松地对网络请求进行配置,例如添加请求头、设置请求方式、设置请求超时等等,这些配置参数会在源码分析过程中详细介绍。
现在我们已经学会了三步操作发起网络请求,接下来以这三个步骤为切入点,深入到源码中学习OkHttp的实现原理,废话少说马上开车。
OkHttpClient创建方式有两种,我们看看两种方式有什么区别。
第一种直接使用默认构造函数,内部依然是使用建造者模式
第二种使用建造者模式
两种方式最终都是调用构造函数OkHttpClient(builder:Builder),由参数builder负责所有的参数配置工作。
当您创建单个OkHttpClient实例并将其用于所有 HTTP 调用时,OkHttp 性能最佳。 这是因为每个OkHttpClient都拥有自己的连接池和线程池,重用连接和线程可减少延迟并节省内存。 相反,为每个请求创建一个客户端会浪费空闲池上的资源。
Request同样使用建造者模式来创建,这里贴上部分重要源码,很简单就不细说了。
OkHttp发起网络请求分为同步请求和异步请求两种方式,我们只分析异步请求流程,因为只要理解了异步请求过程,基本上也就明白同步请求是怎么一回事了。
RealCall是连接应用层与网络层的桥梁,负责处理连接、请求、响应和数据流。
Dispatcher维护着一套异步任务执行策略,分析策略之前先介绍几个重要概念:
client.dispatcher.enqueue(AsyncCall(responseCallback)) 执行步骤为:
AsyncCall实现了Runnable接口,因此一旦被线程池中的线程处理就会调用它的run()方法:
话休絮烦,我们开始分析拦截器责任链:
责任链执行流程:首先获取当前拦截器interceptor,并且调用interceptor.intercept(next)执行拦截器操作。这里的next表示的是index+1后的责任链对象,拦截器的intercept()方法内部会调用next.proceed(request)方法再次进入到责任链,由于此时index已经加1,所以处理的是下一个拦截器。
如此循环往复,直到处理完责任链上最后一个拦截器为止。
注意除最后一个拦截器CallServerInterceptor不会调用chain.proceed(request)方法之外,其他拦截器都应该至少调用一次chain.proceed(request)方法。
为了验证上面的结论,我们进入到RetryAndFollowUpInterceptor的intercept()方法一探究竟:
可以看到注释1处重新进入责任链处理下一个拦截器。
有兴趣可以自行查看最后一个拦截器CallServerInterceptor源码,此处只给出本人阅读源码后得出的结论:
以上就是拦截器责任链的工作流程,我们再通过流程图仔细感受一下。
分析完拦截器责任链,我们继续分析AsyncCall#run()方法:
我们看到,如果getResponseWithInterceptorChain()方法成功获得服务端返回的数据,则调用responseCallback.onResponse(this@RealCall, response)方法完成异步回调;如果服务端数据获取失败(请求异常),则调用responseCallback.onFailure(this@RealCall, canceledException)方法完成异步回调
需要注意的是,responseCallback回调是在子线程中完成的,所以如果想把数据显示到UI上,需要切换回主线程进行UI操作。
OkHttp发起网络请求全过程:
【知识点】OkHttp 原理 8 连问