如何理解SCP Application Router

這期內容當中小編將會給大家帶來有關如何理解SCP Application Router，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

---



簡單解釋一下主要的參數：

Routes

• source:可以是一個URL，也可以是一個正則表達式，定義了當前的route是匹配什么樣的請求路徑

• target: 當前請求如何被重寫到目標地址

• destination: 當前請求路由到manifest中的哪個目標地址

• authenticationType: 有三種選擇，xsuaa, none和basic，xsuaa和none分別代表了是否對當前請求在App Router上做用戶安全認證，下一節會具體介紹。Basic是和SAP HANA集成的時候提供默認的安全驗證支持。

Destination

• Name:用來跟xs-app.json中的destination配置相匹配

• URL:目標應用程序真實的Clould Foundry地址

• ForwardAuthToken: 如果請求中帶有oauth token，是否將oauth token轉發給目標應用程序. App Router也支持oauth token的部分校驗功能，所以用戶也可以根據具體情況選擇不轉發oauth token，就在App Router端校驗

除了基本的路由功能，App Router還提供了豐富的Web應用程序相關的功能支持，比如連接管理，session管理，擴展http頭，跨域，Web Socket等等。

App Router和SCP UAA的安全集成

如上一節提到的，App Router在路由的時候提供了用戶的安全認證支持。將路由的Authentication Type配置為xsuaa，App Router則會檢查前端發過來的請求是否帶有合法的session。如果沒有，App Router會將用戶導向SCP UAA的用戶認證界面，當用戶重新認證成功之后，會生成新的合法session，并將此session返回給前端應用程序。

整個認證的流程是是SCP App Router和SCP UAA協同完成的，SCP UAA是SAP對Cloud Foundry上提供的安全組件UAA (User Account and Authentication Service)的一個封裝，Cloud Foundry UAA是一個實現了標準Oauth 2.0協議的authorization server，SAP在此基礎上做了一些自定義的增強，但是在接口上和原生的UAA保持了一致，這樣可以盡可能的對OAuth Client端程序提供兼容性。

Cloud Foundry UAA官方文檔:

https://docs.cloudfoundry.org/api/uaa/version/4.10.0/index.html#overview

SCP標準的OAuth3.0流程:



如果熟悉OAuth3.0協議，從這張流程圖上很快就能看出App Router和UAA之間是通過Authorization Code Grant Flow來交互的，在交互過程中它們分別充當了OAuth Client和OAuth Server的角色。

關于OAuth3.0，請參見: https://oauth.net/2/

看到這里您也許會問，為什么不是前端瀏覽器作為OAuth Client？除了安全性的考慮， App Router將OAuth流程對前端隱藏的另一個好處是，各種前端應用程序不需要知道UAA上諸如Client ID, Client Secret的細節，提供了更好的安全性。

其次還有SAP在產品層面的考量，為了其標準的產品在UI技術上的一致性，包括SCP上的產品在內大多數都是基于SAP UI5來構建前端UI，而UI5又是基于HTML5技術而來，即這些產品都是基于瀏覽器的富客戶端應用。如此一來，在標準的App Router里面實現OAuth3.0流程可以使SAP的各種前端應用并不需要關注認證流程的細節。如上圖所示，App Router在完成了認證流程并最終拿到token之后，并沒有將token返回給瀏覽器端，而是在App Router上生成一個session，并且將session和token關聯起來，App Router在這里起到一個中介者的角色，對于前端統一用session進行交互，對于后端統一用token進行交互。

SCP除了將標準的實現默認支持瀏覽器端應用程序外，作為一個開放的平臺，當然也支持移動端原生應用程序的集成，這里不作贅述，具體細節可以參考SCP的開發文檔。

App Router上的session管理

App Router上的session管理利用了Node.js的session-express框架，默認將session緩存在instance memory中(下圖第79行):



然后采用session stickiness策略來保證在多實例部署的情況下，相同會話的請求會被發送到同一個實例上以保證會話能繼續進行。

Session Stickiness:

https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions

這樣做的好處是既利用了instance memory的高性能，也可以在一定程度上保證高可靠性。不過代價是犧牲了動態伸縮的能力，一旦某個App Router實例上還有正在使用中的session，這個實例就不能被關閉。

好在App Router使用的是開源的express-session框架，該框架并非只能將session存儲在instance memory中，在Node.js開源社區已經提供了多種express-session的外部存儲方案。至少在技術上，可以將App Router提供的instance memory存儲替換為外部存儲，而不需要做太多的定制化開發，這樣一來多個App Router實例就可以共享同一套session存儲。

App Router的可擴展性

只要說到SAP的產品，extensibility是一個不可避免的話題，這是由SAP的業務是面向企業級客戶這一特質決定的。SAP也一直致力于從平臺到框架，再到上層的產品，盡可能多的給SAP客戶提供良好的可擴展性。App Router同樣也不例外，因為直接使用了Node.js的connect框架，這是一款本身就提供了豐富擴展的中間件框架，可以通過可插拔的方式對Node.js的請求和響應提供過濾和攔截，具體大家可以參考connect的主頁。

App Router基于connect,當然App Router的用戶就可以直接獲得connect提供的各種中間件，除此之外App Router還提供了自己的一些中間件:



是不是非常簡單和直接？使用這些中間件而不需要修改原生App Router里面的代碼。

這里不再對App Router上的各種中間件一一贅述。

總結說來，App Router是一款設計簡單，使用方便，提供了良好可擴展性的反向代理組件，為廣大SAP用戶在SCP上開發應用程序提供了更多的選擇和方便。

上述就是小編為大家分享的如何理解SCP Application Router了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。