如何理解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了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注编程网精选频道。