我們在控制器上使用帶有@RestController注釋的spring mvc,我們正在處理控制器中的授權.我們使用相同的代碼來設置響應CORS飛行前請求的允許方法.為實現(xiàn)這一目標,我們有：

在調度程序servlet的配置中,然后我們有：

@RequestMapping(value="/some/collections",method=RequestMethod.OPTIONS)

public void collectionOptions(

HttpServletRequest req,HttpServletResponse res) {

List

我們還有一個攔截器,它對CORS pre-flight進行基本檢查,以查看原點是否可能具有任何權限.

我們這樣做主要是因為某些請求的權限實際上取決于@RequestParams,即：

OPTIONS /api/collections?userId=122

如果您具有管理權限,或者您實際上是具有ID 122的用戶,則可能被允許.此外,我們還有API密鑰

OPTIONS /api/collections?userId=122&apiKey=ABC

對于一個原點可能沒問題,但對另一個原點則不行.

這工作正常,但是現(xiàn)在,Spring 4.2決定是否處理OPTIONS請求,通過調用：

CorsUtils.isCorsRequest(request);

在AbstractHandlerMapping中然后返回

HandlerInterceptor[] interceptors = chain.getInterceptors();

chain = new HandlerExecutionChain(new PreFlightHandler(config),interceptors);

而不是HandlerMethod ……

我們需要的是告訴spring讓控制器處理OPTIONS請求的一些方法,無論預檢請求處理程序是什么.

我們似乎無法找到一個點,我們可以告訴內置的CORS處理是安靜的,或者在某個地方配置一些允許我們繞過新添加的代碼的子類：

AbstractHandlerMapping.getHandler(HSR request)

這有可能嗎？在我主動啟用它之前(通過WebMvcConfigurerAdapter或通過@CrossOrigin注釋),這樣的功能是不是很安靜？

——–編輯————-

HTTP標準說明了以下關于OPTIONS方法的內容：

OPTIONS方法表示請求有關Request-URI標識的請求/響應鏈上可用的通信選項的信息.該方法允許客戶端確定與資源相關聯(lián)的選項和/或要求,或服務器的能力,而不暗示資源動作或啟動資源檢索.

認為beyong只是CORS,我認為攔截CORS選項調用雖然相應的方法映射到控制器上是不正確的方法.是的,CORS是你可以用OPTIONS調用做的一件事.但它絕不是唯一的一個.

如果沒有映射,并且如果使用不同的請求方法和@CrossOrigin注釋映射處理程序方法,我希望觸發(fā)內置CORS支持的假設會很好,但我不認為任何請求原始標頭集應該只自動轉到CORS處理程序.

總結

以上是生活随笔為你收集整理的java option请求_java – 如何说服spring 4.2将OPTIONS请求传递给控制器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。