国产a∨精品一区二区三区不卡_国产成人精品免费视频大全麻豆_亚洲国产精品毛片Aⅴ不卡在线_天堂不卡一区二区在线网站

七、接口版本控制

1、簡介

在SpringBoot項目中，如果要進行restful接口的版本控制一般有以下幾個方向：

基于path的版本控制
基于header的版本控制

在spring MVC下，url映射到哪個method是由RequestMappingHandlerMapping來控制的，那么我們也是通過RequestMappingHandlerMapping來做版本控制的。

2、Path控制實現

首先定義一個注解

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiVersion {
    // 默認接口版本號1.0開始，這里我只做了兩級，多級可在正則進行控制
    String value() default "1.0";
}

ApiVersionCondition用來控制當前request 指向哪個method

public class ApiVersionCondition implements RequestCondition<ApiVersionCondition> {
    private static final Pattern VERSION_PREFIX_PATTERN = Pattern.compile("v(\\\\d+\\\\.\\\\d+)");

    private final String version;

    public ApiVersionCondition(String version) {
        this.version = version;
    }

    @Override
    public ApiVersionCondition combine(ApiVersionCondition other) {
        // 采用最后定義優先原則，則方法上的定義覆蓋類上面的定義
        return new ApiVersionCondition(other.getApiVersion());
    }

    @Override
    public ApiVersionCondition getMatchingCondition(HttpServletRequest httpServletRequest) {
        Matcher m = VERSION_PREFIX_PATTERN.matcher(httpServletRequest.getRequestURI());
        if (m.find()) {
            String pathVersion = m.group(1);
            // 這個方法是精確匹配
            if (Objects.equals(pathVersion, version)) {
                return this;
            }
            // 該方法是只要大于等于最低接口version即匹配成功，需要和compareTo()配合
            // 舉例：定義有1.0/1.1接口，訪問1.2，則實際訪問的是1.1，如果從小開始那么排序反轉即可
//            if(Float.parseFloat(pathVersion)>=Float.parseFloat(version)){
//                return this;
//            }

        }
        return null;
    }

    @Override
    public int compareTo(ApiVersionCondition other, HttpServletRequest request) {
        return 0;
        // 優先匹配最新的版本號，和getMatchingCondition注釋掉的代碼同步使用
//        return other.getApiVersion().compareTo(this.version);
    }

    public String getApiVersion() {
        return version;
    }

}

PathVersionHandlerMapping用于注入spring用來管理

public class PathVersionHandlerMapping extends RequestMappingHandlerMapping {

    @Override
    protected boolean isHandler(Class? beanType) {
        return AnnotatedElementUtils.hasAnnotation(beanType, Controller.class);
    }

    @Override
    protected RequestCondition? getCustomTypeCondition(Class? handlerType) {
        ApiVersion apiVersion = AnnotationUtils.findAnnotation(handlerType,ApiVersion.class);
        return createCondition(apiVersion);
    }

    @Override
    protected RequestCondition? getCustomMethodCondition(Method method) {
        ApiVersion apiVersion = AnnotationUtils.findAnnotation(method,ApiVersion.class);
        return createCondition(apiVersion);
    }

    private RequestCondition

WebMvcConfiguration配置類讓spring來接管

@Configuration
public class WebMvcConfiguration implements WebMvcRegistrations {

    @Override
    public RequestMappingHandlerMapping getRequestMappingHandlerMapping() {
        return new PathVersionHandlerMapping();
    }
}

最后controller進行測試，默認是v1.0，如果方法上有注解，以方法上的為準（該方法vx.x在路徑任意位置出現都可解析）

@RestController
@ApiVersion
@RequestMapping(value = "/{version}/test")
public class TestController {

    @GetMapping(value = "one")
    public String query(){
        return "test api default";
    }

    @GetMapping(value = "one")
    @ApiVersion("1.1")
    public String query2(){
        return "test api v1.1";
    }


    @GetMapping(value = "one")
    @ApiVersion("3.1")
    public String query3(){
        return "test api v3.1";
    }
}

3、header控制實現

總體原理與Path類似，修改ApiVersionCondition即可，之后訪問時在header帶上X-VERSION參數即可

public class ApiVersionCondition implements RequestCondition<ApiVersionCondition> {
    private static final String X_VERSION = "X-VERSION";
    private final String version ;
    
    public ApiVersionCondition(String version) {
        this.version = version;
    }

    @Override
    public ApiVersionCondition combine(ApiVersionCondition other) {
        // 采用最后定義優先原則，則方法上的定義覆蓋類上面的定義
        return new ApiVersionCondition(other.getApiVersion());
    }

    @Override
    public ApiVersionCondition getMatchingCondition(HttpServletRequest httpServletRequest) {
        String headerVersion = httpServletRequest.getHeader(X_VERSION);
        if(Objects.equals(version,headerVersion)){
            return this;
        }
        return null;
    }

    @Override
    public int compareTo(ApiVersionCondition apiVersionCondition, HttpServletRequest httpServletRequest) {
        return 0;
    }
    public String getApiVersion() {
        return version;
    }

}

八、API接口安全

1、簡介

APP、前后端分離項目都采用[API]接口形式與服務器進行數據通信，傳輸的數據被偷窺、被抓包、被偽造時有發生，那么如何設計一套比較安全的API接口方案至關重要，一般的解決方案有以下幾點：

Token授權認證，防止未授權用戶獲取數據；
時間戳超時機制；
URL簽名，防止請求參數被篡改；
防重放，防止接口被第二次請求，防采集；
采用HTTPS通信協議，防止數據明文傳輸；

2、Token授權認證

因為HTTP協議是無狀態的，Token的設計方案是用戶在客戶端使用用戶名和密碼登錄后，服務器會給客戶端返回一個Token，并將Token以鍵值對的形式存放在緩存（一般是Redis）中，后續客戶端對需要授權模塊的所有操作都要帶上這個Token，服務器端接收到請求后進行Token驗證，如果Token存在，說明是授權的請求。

Token生成的設計要求

應用內一定要唯一，否則會出現授權混亂，A用戶看到了B用戶的數據；
每次生成的[Token]一定要不一樣，防止被記錄，授權永久有效；
一般Token對應的是Redis的key，value存放的是這個用戶相關緩存信息，比如：用戶的id；
要設置Token的過期時間，過期后需要客戶端重新登錄，獲取新的Token，如果[Token]有效期設置較短，會反復需要用戶登錄，體驗比較差，我們一般采用Token過期后，客戶端靜默登錄的方式，當客戶端收到[Token]過期后，客戶端用本地保存的用戶名和密碼在后臺靜默登錄來獲取新的[Token]，還有一種是單獨出一個刷新Token的接口，但是一定要注意刷新機制和安全問題；

根據上面的設計方案要求，我們很容易得到Token=md5(用戶ID+登錄的時間戳+服務器端秘鑰)這種方式來獲得Token，因為用戶ID是應用內唯一的，登錄的時間戳保證每次登錄的時候都不一樣，服務器端秘鑰是配置在服務器端參與加密的字符串（即：鹽），目的是提高Token加密的破解難度，注意一定不要泄漏

3、時間戳超時機制

客戶端每次請求接口都帶上當前時間的時間戳timestamp，服務端接收到timestamp后跟當前時間進行比對，如果時間差大于一定時間（比如：1分鐘），則認為該請求失效。 時間戳超時機制是防御DOS攻擊的有效手段。 例如http://url/getInfo?id=1&timetamp=1661061696

4、URL簽名

寫過支付寶或微信支付對接的同學肯定對URL簽名不陌生，我們只需要將原本發送給server端的明文參數做一下簽名，然后在server端用相同的算法再做一次簽名，對比兩次簽名就可以確保對應明文的參數有沒有被中間人篡改過。例如http://url/getInfo?id=1&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e

簽名算法過程

首先對通信的參數按key進行字母排序放入數組中（一般請求的接口地址也要參與排序和簽名，那么需要額外添加url=http://url/getInfo這個參數）
對排序完的數組鍵值對用&進行連接，形成用于加密的參數字符串
在加密的參數字符串前面或者后面加上私鑰，然后用md5進行加密，得到sign，然后隨著請求接口一起傳給服務器。服務器端接收到請求后，用同樣的算法獲得服務器的sign，對比客戶端的sign是否一致，如果一致請求有效

5、防重放

客戶端第一次訪問時，將簽名sign存放到服務器的Redis中，超時時間設定為跟時間戳的超時時間一致，二者時間一致可以保證無論在timestamp限定時間內還是外 URL都只能訪問一次，如果被非法者截獲，使用同一個URL再次訪問，如果發現緩存服務器中已經存在了本次簽名，則拒絕服務。

如果在緩存中的簽名失效的情況下，有人使用同一個URL再次訪問，則會被時間戳超時機制攔截，這就是為什么要求sign的超時時間要設定為跟時間戳的超時時間一致。拒絕重復調用機制確保URL被別人截獲了也無法使用（如抓取數據）

方案流程

客戶端通過用戶名密碼登錄服務器并獲取Token；
客戶端生成時間戳timestamp，并將timestamp作為其中一個參數；
客戶端將所有的參數，包括Token和timestamp按照自己的簽名算法進行排序加密得到簽名sign
將token、timestamp和sign作為請求時必須攜帶的參數加在每個請求的URL后邊，例：http://url/request?token=h40adc3949bafjhbbe56e027f20f583a&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e
服務端對token、timestamp和sign進行驗證，只有在token有效、timestamp未超時、緩存服務器中不存在sign三種情況同時滿足，本次請求才有效；