一种基于nginx与阿波罗达到接口权限校验的方法

技术领域

本发明涉及互联网金融领域，特别涉及一种基于nginx与阿波罗达到接口权限校验的方法。

背景技术

随着互联网的发展，在现有的业务场景中，开放平台承载着对外提供服务的能力，用户的请求先到开放平台，再经开放平台转发至后面的业务平台。在网络的交互过程中会存在公网和专线，对客的时候大多是使用公网接口，而电信集团内的交互大多是使用cn2,dcn的专线交互。纵观现有的技术解决方案，相同的一个功能，在开放平台的代码里要写两套一模一样的接口代码，一套专门给公网的请求使用，另一套专门给专线的请求使用，而底层逻辑是一模一样。这种重复造轮子，耗时耗力，而且过多的垃圾代码还占用了git服务器的资源，给技术人员增加了运维的难度。此外，当前的网络环境，要时刻注意公网和专线的请求是否会存在越权的问题。

发明内容

本发明要解决的技术问题是克服现有技术的缺陷，提供一种基于nginx与阿波罗达到接口权限校验的方法，创新地在开放平台使用一套代码且针对接口级别进行了细化区别配置网络公网和专线的标识，进而对外暴露出公网和专线两个不同的接口，应用代码底层通过校验数据库的接口网络公网专线标识和应用集群对应的阿波罗网络公网专线标识，完成了公网和专线的隔离，同时请求不会相互越权。底层使用同一套代码，使得接口功能无须重复开发，无须占用git服务器的资源，降本增效，避免过多的无用代码扰乱开发运维人员的视线，降低了技术人员运维维护的难度。

本发明提供了如下的技术方案：

本发明提供一种基于nginx与阿波罗达到接口权限校验的方法，包括以下：

1)应用部署，在开放平台应用运营部署的时候，对外公布的公网接口地址和专线地址两套，负责负载均衡的nginx部署公网和专线两套，阿波罗配置也指向公网和专线两套，而代码是同一套；底层代码是同一个接口，但向外提供了公网和专线的两个对外接口地址；这样自流量入口，到nginx服务器从物理上是已隔离出来；但是这仅仅是物理隔离，如果存在专线的请求往公网发送或者是公网的请求往专利发送这种恶意调用，还是会有安全风险；所以还需进行后续的步骤；即对外有两个地址，而对内对应的是同一个接口；

2)阿波罗配置，阿波罗是携程开源的配置管理中心,能够集中化管理不同环境、不同集群的配置,配置修改后能实时推送到应用端,并且具备权限管理的特性，这个可随部署不同的应用名而有不同的配置属性；公网集群里在阿波罗的网络配置标识中为PUBLIC公网，专线集群在阿波罗的网络配置标识中为PRIVATE专线；阿波罗的公网和专线的配置，达到了从阿波罗配置层面对集群进行公网和专线的隔离；

3)接口配置，在开放平台会有一张对外接口配置表，表中会标明对外提供的地址属性是公网还是专线；对外接口配置表，使得对接口的配置更加的灵活，可针对公网或者是专线接口级别的进行配置网络标识，可详细地对某一接口配置成公网接口或者是专线接口；

4)公网请求，开放平台接收到公网的请求之后，经公网的nginx转发至公网对应的应用集群，应用集群里的代码会查询开放平台接口配置表，将接口对应的公网专线标识查询出来；然后将查询出来的标识和当前应用集群的阿波罗配置进行核对，确保数据库中的网络配置标识和阿波罗配置的网络标识一样，才允许通过；否则返回“无接口权限“给调用方，流程结束；

5)专线请求，开放平台接收到专线的请求之后，经专线的nginx转发至专线对应的应用集群，应用集群里的代码会查询开放平台接口配置表，将接口对应的专线专线标识查询出来；然后将查询出来的标识和当前应用集群的阿波罗配置进行核对，确保数据库中的网络配置标识和阿波罗配置的网络标识一样，才允许通过；否则返回“无接口权限“给调用方，流程结束；

6)恶意攻击，假设网络确实被攻破，从而公网的请求转发至专线集群或者是专线的集群转发至公网，请求去到开放平台的逻辑代码校验环节，通过接口数据库网络标识和阿波罗网络标识校验的过程中就会识别出来，返回“无接口权限“给调用方，达到了公网和专线相互隔离，接口权限控制的目的。

与现有技术相比，本发明的有益效果如下：

1)底层使用同一套代码，使得接口功能无须重复开发；

2)无须占用git服务器的资源；

3)降本增效；

4)避免过多的无用代码扰乱开发运维人员的视线；

5)降低了技术人员运维维护的难度。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明的翼起来开放平台网络拓扑图；

图2是本发明的接口权限校验时序图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。

实施例1

如图1，翼起来开放平台网络拓扑图：

1).从翼起来入口中层面就分开两个入口，分别是公网入口和专线入口。示例，比如公网对外的接口：

https://plateform-in.net/tyt-gw/sale-data/push/public，专线对外的接口：https://plateform-in.net/tyt-gw/sale-data/push/private，公网和专线提供了两个不同的地址，经nginx转发之后其实都映射至开放平台的/sale-data/push实销数据推送同一个接口。即对外有两个地址，而对内对应的是同一个接口。

2).nginx方面亦部署了公网和专线两套，用于进行网络请求的转发。公网的nginx转发至公网的开放平台应用，专线的nginx转发至专线的nginx应用。

3).作为统一前置的开放平台tyt-open-plateform-in模块则用相同的一套代码进行部署，创新的是针对接口级别进行配置且细化区分至公网和专线接口，以此来校验公网或者是专线的请求，达到了只用一套开放平台的代码通过入口、ngnix、应用和接口级别的权限控制达到了公网和专线的隔离，避免了重复开发代码，节约成本，降低了开发运维的难度；

4).阿波罗配置区分了公网和专线两套，阿波罗是携程开源的配置管理中心,能够集中化管理不同环境、不同集群的配置,配置修改后能实时推送到应用端,并且具备权限管理的特性。这个可随部署不同的应用名而有不同的配置属性；

5).底层的数据库，redis等中间件则共用。

如图2，接口权限校验时序图：

1).渠道业务模块调用翼起来公网入口，发起请求，翼起来公网接口接收到请求经公网nginx转发，最终请求去到翼起来公网开放平台；

2).翼起来公网开放平台接收到来自公网的请求后，根据当前请求接口的url去查询数据库的接口配置。

3).判断当前请求接口的url和当前阿波罗的配置是否一致。由于该请求是请求至公网的开放平台应用，所以阿波罗的配置属性为公网。理论上请求去到本应用上的都应是公网应用。所以当判断请求对应的网络标识不是公网时，则返回“无接口权限“给调用方，流程结束，达到了接口权限控制的目的。

4).渠道业务模块调用翼起来专线入口，发起请求，翼起来专线接口接收到请求经专线nginx转发，最终请求去到翼起来专线开放平台；

5).翼起来专线开放平台接收到来自专线的请求后，根据当前请求接口的url去查询数据库的接口配置。

6).判断当前请求接口的url和当前阿波罗的配置是否一致。由于该请求是请求至专线的开放平台应用，所以阿波罗的配置属性为专线。理论上请求去到本应用上的都应是专线应用。所以当判断请求对应的网络标识不是专线时，则返回“无接口权限“给调用方，流程结束，达到了接口权限控制的目的。示例：假设当前的外部请求的接口地址是公网接口https://plateform-in.net/tyt-gw/sale-data/push/public，此接口在后端数据库中配置的网络属性是公网PUBLIC，意味着此接口只能在公网中使用，在专线中不能使用。假设当前的外部请求的接口地址是专线接口https://plateform-in.net/tyt-gw/sale-data/push/private，此接口在后端数据库中配置的网络属性是专线PRIVATE，意味着此接口只能在专线中使用，在公网中不能使用。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。