Kendo Grid 教學 4 - 解決 REST Service 回應 HTTP 403

在先前「RestTemplate 無法呼叫 Rest Service」的文章中有提到，有些後台被 Spring Security 保護著，並啟用 Cross-site request forgery (CSRF) 的保護機制，並免他人因為知道服務的端點，就可以直接呼叫相關的服務。

Kendo UI 可以透過 Datasource 中 transport 的屬性設定，可以完成資料的讀取及寫入工作。針對新增、修改、刪除及查詢的部分，分別提供 create、update、destory 及 read 的 function 來進行相關作業的處理。

    transport:{
        create:{...},
        update:{...},
        destroy{...},
        read{...}
    }

開發人員可透過上述設定，完成 kendo grid 上 CRUD 的相關動作。

但是，當我們碰上後端具有 CSRF 保護的服務時，可能會出現 「HTTP 403 : Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'」的錯誤訊息。

這代表，我們正常地呼叫後端的服務。以整合 Spring Security 來說，當我們完成登入後，可以從 Request Header 中觀察到，HTTP Request 都會帶著兩個 Cookies 的資訊，分別是 JSESSIONID 及 XSRF-TOKEN 資訊。

然後，我們再看一下錯誤的訊息「HTTP 403 : Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'」。看起來，後端要的服務需要我們的 Header 送一個 X-CSRF-TOKEN 的資訊過去。上網找一下參考資料「Invalid CSRF Token 'null' 解決方案」看起來也是這樣說明沒錯。而且，X-CSRF-TOKEN 的內容跟 XSRF-TOKEN 一樣 (一樣的東西，底層竟然沒有自己處理掉 .... 看來還要找時間看看到底為什麼有這樣的限制)。 

所以，接著要思考的是如何在 Kendo Grid 呼叫後端服務時，將  X-CSRF-TOKEN 動態的塞入。後來，我在 「Transport and basic authentication」找到了解答。我們可以在 create、update、destroy 跟 read 等方法上加上 「beforeSend」的方法來加入 X-CSRF-TOKEN。

beforeSend: function(req){
    req.setRequestHeader('X-XSRF-TOKEN', $cookies.get('XSRF-TOKEN'));
}

如此一來，就可以正常使用後端服務了！

[參考資料]
1. 跨網站請求偽造
2. Invalid CSRF Token 'null' 解決方案
3. Transport and basic authentication

RestTemplate 無法呼叫 Rest Service

最近有人問我一個問題，現象是他的應用程式呼叫被 Spring Security 保護的服務時，如果未將 csrf disable，系統就無法正常運作。

Spring Security 啟用 CSRF 後可保護 Server Side 的 Resource，避免跨網域攻擊 (從別的機器發出 Request 以取得後端的資訊)。所以，當 Spring Security 啟用 CSRF 後，我們會在前端的頁面加上

   <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

以便，證明我們是從同一個網域發送的請求。

然而，這個問題卻不是上述原因造成！第一時間的猜想錯誤，所以我就開始檢視程式碼內容，來看看到底那邊出了問題。

後來，發現在後端的程式中有一段使用 RestTemplate 去呼叫 REST 服務。基本上，如果在內部應該可以直接呼叫相關的物件，而不需要透過 RestTemplate 來進行呼叫 (多繞了一圈)。不過，依照範例來看是個教學程式，所以就先不討論合理性的問題。

RestTemplate 其實是一個增強化的 HTTP Client ，所以在使用 RestTemplate 時我們可以想像自己開了一個新的瀏覽器，然後存取該服務。此時，RestTemplate 中根本就沒有儲存相關的 Session。因為他的 Request 中沒有帶任何經過驗證的資訊。所以，會被 Spring Security 視為不合法的存取。

我們必須在 RestTemplate 中加入一些資訊，才可讓這個呼叫合法。相關資訊，可參考下列參考資訊的網址。

HttpHeaders headers = new HttpHeaders();



headers.add("cookie", req.getHeader("cookie"));



HttpEntity requestEntity = new HttpEntity(null, headers);




ResponseEntity rssResponse = 

   restTemplate.exchange( your_service_url,

    HttpMethod.GET,

    requestEntity, List.class);

1. 建立 HttpHeader 物件，並將 request header 中的 cookie 值取出，設定到自己建立的 HttpHeader 中。(因為 Session 就存在這裡)

2. 建立 HttpEntity 物件，並利用先前建立的 HttpHeader 進行初始化。

3. 使用 restTemplate 呼叫後端服務，取得 ResponseEntity 以進行後續邏輯運算

[參考資料]

1. Send Cookies with RestTemplate

Kendo Grid 教學 3 - 建立新增功能

在 「Kendo Grid 教學 2 - Inline Edit」的文章中提到怎麼樣進行 inline edit 的工作。但是，以先前提供的範例來看，並未交代如何進行新增的作業。

但是，如果有依據參考資料進入 「Kendo Grid Grid Inline Edit Demo」檢視範官方的範例程式的話，應該已經發現如何把「Add New Record」的按鈕加上去。

$scope.mainGridOptions = {

         dataSource: $scope.datasource,

         pageable: true,

         height: 300,
         toolbar: ["create"],


         columns: [

          { field: "id",  title: "商品編號", width: "120px"},

          { field: "name", title: "商品名稱", width: "120px" },

          { field: "price", title: "商品價格", width: "120px"},

          { command: ["edit", "destroy"], title: " ", width: "250px" }

          ],
         editable: 'inline'

    };


};

在原本 mainGridOptions 中，加入 toolbar 的元素，並指定要使用 create 功能，就可以像官方的範例，有一個 「Add New Record」的按鈕。

當這個按鈕按下去之後，以 inline 編輯模式來看，Kendo Grid 的第一行會進入編輯模式，讓我們輸入資料後進行新增作業。

[參考資料]
1. Kendo Grid Grid Inline Edit Demo