clientsecret(client secret不匹配)
stripe支付接入步骤
官网：
文档：
1.官网注册账号后，开发者--API密钥,可以获得两个开发密钥
可发布密钥：pk_test_XXXXXX ， 客户端使用
密钥：sk_test_XXXXX ， 服务器使用
2.设置支付方式：
开启Apple pay
至此网站配置简单完成，下面是app配置
1.引入sdk
2.注册api
3.构建快捷支付UI
4.使用
-----------------------------------------------------------------------------
1.根据用户订单，请求服务器，拿到stripe 的 clientSecret
2.构建支付对象，发起支付
3.实现卡片认证的代理
有关认证情况的测试卡如下
clientid和clientsecret怎么生成
clientid和clientsecret生成：
设定一个密钥比如key = ‘2323dsfadfewrasa3434'。这个key 只有发送方和接收方知道。调用时，发送方组合各个参数用密钥 key按照一定的规则(各种排序，MD5，ip等)生成一个access_key，一起post提交到API接口。
如果client_id和client_secret是给专门api提供商使用还是给普通app应用也需要，给专门api提供商使用好理解，就像普通应用的账号密码一样。
原理分析
获取Clientid之前需要把tabelt 的环境切换下，设备测试需要用命令切换下环境。
因为一般情况下默认是线上环境，一般测试都是在 test环境下，所以需要进入cmd ，输入以下命令。adb shell setprop debug.lewindow TEST，然后打开Android studio在logcat中获取Clientid。
如何设计API接口，请求接口时需要进行身份验证，防止第三方随意调用接口？
接口使用方法：
1.接口调用者先申请分配一个clientid，clientsecret，并提供给接口提供者（服务器）一个可访问的callbackURL（用于接口access_token）。
2.接口调用者使用clientid, clientsecret作为参数，向接口提供者发送请求。
接口提供者访问callbackURL发送access_token(有时间限制，超时后重新获取)。
3.接口调用者使用access_token作为参数，调用其他接口获取相关信息。
4.接口调用者在access_token超时后重新获取access_token。
有个疑问：
仅为了防止非法用户随意使用接口，需要这个复杂的机制吗？
接口使用https连接，可以确保数据保密性。
所以是否可以简化上面的流程，仅在接口服务者中配置一个 access_token，
接口使用者只需要提供正确的access_token即可正常使用其他接口。
ClientId、Client-Secret是固定的吗
是。
使用client_id和client_secret可以用来证明客户端的身份，服务器可以知道是哪个客户端在访问。
spring security oauth2 认证端异常处理（基于前后分离统一返回json）
在默认的情况下，spring security oauth2 在发生异常情况下，返回的格式并不符合现实需要，其格式是：
我们一般需要是这种格式
对于oauth2的异常，其类主要是 OAuth2Exception ，默认处理这些异常的是DefaultWebResponseExceptionTranslator,其错误主要是包含oauth2相关的错误，就类似以下的。
DefaultWebResponseExceptionTranslator处理的OAuth2Exception，其类可见的序列化器如下，可以得出默认的返回格式：
所以我们需要重新定义自己的WebResponseExceptionTranslator，以及自己的oauth2异常以及其序列化器(也可以不定义，重写handleOauth2Exception即可)
自定义oauth2异常处理类，CustomWebResponseExceptionTranslator，模仿DefaultWebResponseExceptionTranslator即可，下面给出关键部分，注意result是自己定义返回格式的bean，含有msg和code。最后在认证服务器配置一下就可。
这里说的是oauth2的异常处理，其中还有认证的异常，我们这里使用basic的认证方式，如果发生异常，是不会走这个自定义的异常处理器的，所以在securityConfig中配置,在httpBasic后面配置的那里处理了。
这里加上 http.addFilterBefore(customBasicAuthenticationFilter, BasicAuthenticationFilter.class);
这个filter其实就是验证一些必要参数有无缺失，并且返回自定义的格式，
还有需要注意是：因为是授权码模式，在获取token的时候，需要传clientId和clientSecret，这是获取token的验证我们需要先于一步再到后面，所以我们会定义个过滤器处理,因为在测试过程，如果不先于验证clientId和clientSecret，返回的错误可能不是预期之中的，这里还不清楚为啥会出现那些特殊情况，所以还是先于一步先校验了、
认证服务器配置上自定义的filter，这个filter会先执行再到后面/oauth2/token链接，还有这里不开启allowFormAuthenticationForClients，还是只限于basic，如果开启了，有可能返回不正确的异常格式，具体原因不明，但后续肯定是不走basicFilter的,自定义的filter还是验证参数完整性和认证clientId和clientSecret身份是否正确。
例示参考：
Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程
由身份或持有的令牌确认享有的权限，登录过程实质上的目的也是为了确认权限。
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建立过程