React practice
gitlab-->WebpackBebel-ReactDemo
OAuth2 再识
- 用户访问客户端，客户端将用户导向认证服务器
- 用户选择是否给予客户端授权
- 假设用户给予授权，认证服务器将用户导向客户端事先指定的重定向URI，同时附上一个授权码
- 客户端收到授权码，附上早先的重定向URI，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见
- 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）等
第一步：
客户端申请认证的URI=> https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email
response_type：表示授权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项。
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值
第三步：
服务器将用户导向URI，同时附上授权码 => HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID、重定向URI一一对应。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。
第四步：客户端向认证服务器申请令牌
grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
第五步：认证服务器发送的HTTP回复
Oauth Server返回token，这个时候，就可以通过token获取用户授权的资源了。
access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Refresh token
如果用户访问的时候，客户端的访问令牌access_token已经过期，则需要使用更新令牌refresh_token申请一个新的访问令牌。
客户端发出更新令牌的HTTP请求，包含以下参数：
grant_type：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。
refresh_token：表示早前收到的更新令牌，必选项。
scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
semver 语义化版本规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号：发布正式版之前的版本，如：
alpha：是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。1.0.0-alpha
beta：也是测试版，这个阶段的版本会一直加入新的功能。在Alpha版之后推出
rc：Release Candidate) 系统平台上就是发行候选版本。RC版不会再加入新的功能了，主要着重于除错。
定义依赖版本号：
^ ：表示同一主版本号中，不小于指定版本号的版本号
^2.2.1 ==> 2.2.1、2.2.2、2.3.0 ,主版本号固定
~ ：表示同一主版本号和次版本号中，不小于指定版本号的版本号
~2.2.1 ==> 2.2.1、2.2.2，主版本号和次版本号固定
<、>、=、>=、<=、-：用来指定一个版本号范围
>2.1
1.0.0 - 1.2.0
||：表示或
x、X、*：表示通配符
3.x ==> 所有主版本号为 3 的版本号
