CN115378645A - 一种基于电力营销管理系统统一认证的验证方法及系统 - Google Patents

Abstract

一种基于电力营销管理系统统一认证的验证方法及系统，包括以下步骤：电力营销管理系统用户通过客户端向API网关发送请求；API网关根据接收到的请求判断其是否需要认证；若判断为需要认证，则API网关通过全局过滤器判断请求是否携带token；若请求未携带token则认证失败，若请求携带token则通过API接口验证请求携带的token是否有效；若请求携带的token无效则认证失败，若请求携带的token有效则认证成功，获取用户id并将其放入请求头部，用于电力营销管理系统微服务调用；当用户登出时，客户端销毁token。本发明解决了电力营销管理系统中各应用访问的统一内网入口登陆，进行用户统一授权认证校验，服务内部不再做登陆认证，具有良好的快捷性、简易性、安全性、适应性和扩展性。

Description

一种基于电力营销管理系统统一认证的验证方法及系统

技术领域

本发明属于认证通信技术领域，更具体地，涉及一种基于电力营销管理系统统一认证的验证方法及系统。

背景技术

随着互联网技术的迅猛发展，在电力营销管理系统中，逐渐出现包括移动端、大屏、网厅端等多个应用场景，且网络资源、用户访问与授权信息交互增多，从而对电力营销管理系统的快捷性、简易性、安全性、适应性、扩展性都提出了很高的要求，随着电力营销管理系统中的具体应用项目种类逐渐增多，每个应用项目单独管理各自的用户数据容易行成信息孤岛，分散的用户管理模式阻碍了应用向平台化演进。当电力营销管理系统的互联网业务发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，统一化管理能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，且能够实现单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。

面对不断增加的应用场景和用户认证需求，如何梳理网络秩序，统筹协调，通过统一的安全策略进行整合管理是电力营销管理系统急速扩大过程中急需解决的问题。

发明内容

为解决现有技术中存在的不足，本发明的目的在于，提供一种基于电力营销管理系统统一认证的验证方法及系统，通过统一的安全策略对系统的用户和应用进行整合管理。

本发明采用如下的技术方案。

一种基于电力营销管理系统统一认证的验证方法，包括以下步骤：

步骤1，电力营销管理系统用户通过客户端向API网关发送请求；

步骤2，API网关根据接收到的请求判断其是否需要认证；

步骤3，若判断为需要认证，则API网关通过全局过滤器判断请求是否携带token；

步骤4，若请求未携带token则认证失败，若请求携带token则通过API接口验证请求携带的token是否有效；

步骤5，若请求携带的token无效则认证失败，若请求携带的token有效则认证成功，获取用户id并将其放入请求头部，用于电力营销管理系统的微服务调用；

步骤6，当用户登出时，客户端销毁token。

优选地，用户通过客户端向API网关发送请求的场景包括：PC端内网用户通过web向API网关发送请求，PC端外网用户通过前置机转内网向API网关发送请求，APP用户通过VPN向API网关发送请求，微信公众号用户通过前置机转换内网向API网关发送请求。

优选地，API网关通过Spring Cloud Gateway和nginx实现，其中，API网关基于Spring Cloud Gateway框架搭建，搭配nginx的反向代理和负载均衡功能。

优选地，判断请求是否需要认证还包括：通过请求携带的url判断是否为登录请求，若接收到的为登录请求则无需认证，否则需要进行认证。

优选地，当API网关接收到的请求为登录请求时，用户通过客户端的登录界面输入对应的登录凭据后进行登录认证。

优选地，所述登录认证包括：

通过API接口进行身份验证，验证通过后，获取该用户的参数，结合参数信息系统给该用户分发一个token并返回给客户端，当用户登录并发送对系统内部各应用的访问请求时，均携带该用户对应的token。

优选地，所述参数包括括用户名、密码和用户id。

优选地，步骤2中的token为会话ID类别token，会话ID类别token还包括浏览器端token、移动端token和API应用token。

优选地，用户携带的token根据电力管理营销系统的应用场景决定，当应用场景为外网网厅web、微信公众号和内网web时采用web_token，应用场景为APP时采用mobile_token，应用场景为大屏时采用api_token。

本发明还提供了一种基于电力营销管理系统统一认证的验证系统，包括：客户端、API网关、API接口、应用程序服务和数据库；

用户通过客户端发送请求向API网关发送请求；

API网关与客户端相连接，通过Spring-Cloud-Gateway和nginx实现，；

API接口能够验证用户请求中携带的token是否有效，API接口为应用程序服务的接口，API网关为API接口间的路由；

应用程序服务为电力营销管理系统中能够向客户提供的各种服务，通过调用API接口用户能够获取相应的服务，

数据库与应用程序服务相连接，用于存储电力营销管理系统中所有数据的集合，应用程序服务能够从数据库中获取所需的数据并反馈给用户。

本发明的有益效果在于，与现有技术相比，本发明采用了一种基于电力营销管理系统统一认证的验证方法及系统，能够提供电力营销管理系统中各应用访问的统一内网入口并使用户通过统一入口进行登陆，进行用户统一授权认证校验，服务内部不再做登陆认证，通过统一的安全策略对系统的用户和应用进行整合管理，具有良好的快捷性、简易性、安全性、适应性和扩展性。

附图说明

图1为本发明中基于电力营销管理系统统一认证的验证方法的整体流程示意图；

图2为本发明中客户端和nginx的连接示意图；

图3为本发明中token的分层结构示意图；

图4为本发明中基于电力营销管理系统统一认证的验证系统的结构交互示意图。

具体实施方式

下面结合附图对本申请作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本申请的保护范围。

本发明提出了一种基于电力营销管理系统统一认证的验证方法，参照图1，图1为该方法的整体流程示意图，包括以下步骤，

步骤1，在电力营销管理系统的不同应用场景下，用户通过客户端向API网关发送请求；

具体的，用户通过客户端向API网关发送请求的场景包括：PC端内网用户通过web向API网关发送请求，PC端外网用户通过前置机转内网向API网关发送请求，APP用户通过VPN向API网关发送请求，微信公众号用户通过前置机转换内网向API网关发送请求。

步骤2，API网关判断接收到的请求是否需要认证；

其中，若接收到的为登录请求则无需认证，本实施例通过url判断是否为登录请求。

进一步的，当API网关接收到的请求为登录请求时，用户通过客户端的登录界面输入对应的登录凭据后进行登录认证，登录认证包括：通过API接口进行身份验证，验证通过后，获取该用户的相应参数，参数包括用户名、密码和用户id，结合参数信息系统给该用户分发一个token(标志)并返回给客户端，客户端存储该token，当用户登录并发送对系统内部各应用的访问请求时，均携带该用户对应的token，token内包含用户对应的user id(用户名称)、回调url(Uniform Resource Locator，统一资源定位器)地址等信息。

步骤3，若判断为需要认证，则API网关通过全局过滤器判断请求是否携带token；

步骤4，若未携带token则认证失败，若携带token则API接口验证请求携带的token是否有效；

其中，若请求未携带token，则认证失败并跳转至登录界面，提示用户需要进行登录。

步骤5，若携带的token无效则认证失败，若携带的token有效则认证成功，获取用户id并将其放入请求头部，用于电力营销系统的微服务调用；

步骤6，当用户登出时，客户端销毁token。

其中，API网关能够降低网络延迟，通过API网关使用单一的统一入口和一致的方法管理请求，进行用户身份鉴权校验、指标收集和响应转换等安全管理任务。本实施例中，API接口为电力管理营销系统中的应用程序接口，API网关为接口间的路由。

进一步的，本发明中API网关通过Spring-Cloud-Gateway和nginx实现，其中，API网关基于Spring-Cloud-Gateway框架搭建，其主要作用包括转发服务、接收内外部的客户端调用问题、常用功能权限认证和限流管控等，能够简化前端的调用逻辑和系统内部服务之间相互调用的复杂度；为了确保用户发送请求的安全性和稳定性，搭配nginx的反向代理和负载均衡功能，从而提高API网关的安全性和容错率，反向代理功能能够隐藏真实的服务器地址，负载均衡用于处理系统高并发下的服务需求，nginx通过异步非阻塞的方式来处理请求。

具体的，Spring-Cloud-Gateway用于提供一种简单而有效的途径来发送API，向其提供交叉关注点，并且基于过滤器链的方式提供动态路由、监控、指标、限流、路径重写功能，底层通信框架核心特征包括过滤器(Filter)、路由(Route)和断言(Predicate)。

其中，过滤器为路由转发请求时所经过的过滤逻辑，可用于修改请求、响应内容，使用过滤器拦截和修改请求，并且对上游的响应，进行二次处理。

路由为网关配置的基本组成模块，每个路由模块由一个ID(名称)，一个目标URI(统一资源定位器)，一组断言和一组过滤器定义，根据断言进行匹配转发，若断言为真，则路由匹配，目标URI会被访问。

本实施例采用Java8的断言，断言为路由转发的判断条件，可以用于匹配来自HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求的任何内容，例如headers或参数，其输入类型是一个Server-Web-Exchange。

客户端向Spring-Cloud-Gateway发出请求，然后在Gateway-Handler-Mapping中找到与请求相匹配的路由，将路由发送至Gateway-Web-Handler。Handler再通过指定的过滤器链来将请求发送到实际的服务执行业务逻辑，然后返回，过滤器之间的虚线表示过滤器可能会在发送代理请求之前(“pre”)或之后(“post”)执行业务逻辑。

本实施例中针对电力营销管理系统，Spring-Cloud-Gateway采用和注册中心相结合的路由配置方式，在uri的schema协议部分为自定义的lb：类型，表示从微服务注册中心订阅服务，并且进行服务的路由。断言采用通过请求路径、请求方式、请求参数、Header属性、Cookie(储存在用户本地终端上的数据)等组合匹配匹配规则，便于接收到的请求找到对应的路由并进行处理。本实施例中的Spring-Cloud-Gateway作为API网关的框架，其主要作用是转发服务，接收内外部的客户端调用问题，常用功能权限认证、限流管控等，能够简化前端的调用逻辑，同时也简化了电力营销管理系统内部服务之间相互调用的复杂度。

进一步的，在高并发场景中使用限流手段从而有效的保障服务的整体稳定性，本实施例采用Spring-Cloud-Gateway提供了基于Redis(Remote Dictionary Server，远程字典服务)的限流方案。添加对应的依赖包spring-boot-starter-data-redis-reactive，在配置文件中需要添加Redis地址和限流的相关参数配置，涉及参数如下：过滤器Filter，其名称必须为RequestRateLimiter；redis-rate-limiter.replenishRate，即允许用户每秒处理多少个请求；redis-rate-limiter.burstCapacity，表示令牌桶的容量，即允许在一秒钟内完成的最大请求数；key-resolver，使用SpEL(Spring Expression Language，Spring表达式语言)按名称引用bean；根据请求参数中的user字段来限流。

具体的，API网关通过熔断保护步骤1中发送请求的服务，例如A服务调用B服务的API接口，若B服务接口变得不稳定，即表现为接口延迟或者失败率变大，此时如果对B服务的调用不能快速失败，那么就会导致A服务大量线程资源无法释放导致，最终导致A服务不稳定，从而故障点由B服务传递到A服务，故障扩大。熔断就是在B服务出现故障的情况下，快速断开对B的调用，通过快速失败来保证A服务的稳定，减少故障扩大的影响。本实施例利用Spring-Cloud-Gateway的Hystrix熔断特性，在流量过大时进行服务降级。首先给系统添加依赖，然后使用myCommandName作为名称生成HystrixCommand对象来进行熔断管理。

在调用API接口的时候，若由于某种原因调用失败，此时可以通过重试的方式，来重新请求接口，重试也要注意应用场景，读数据的接口比较适合重试的场景，写数据的接口就需要注意接口的幂等性，以及重试次数如果太多的话会导致请求量加倍，给后端造成更大的压力，因此需要设置合理的重试机制，本实施例中系统通过Retry-Gateway-Filter的retries、statuses、methods和series参数控制重试机制。

参照图2的示意，图2为客户端和nginx的连接示意图。其中，反向代理即客户端对代理是无感知的，因为客户端不需要任何配置就可以进行访问，只需要将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，在返回给客户端，此时反向代理服务器和目标服务器对外可以看做一个整体服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址，该过程具体操作步骤如下：

模拟若干个http服务器作为目标主机：在本实施例中使用tomcat搭建3台http服务器，分别为192.168.0.3，192.168.0.4，192.168.0.5，物理前置机10.100.11.5；

Host配置IP域名：3台http服务器Host中分别配置为192.168.0.310.100.11.5；192.168.0.410.100.11.5；192.168.0.510.100.11.5；前置机服务器配置外网10.100.11.5xxx.com；

配置nginx.conf；

浏览器访问IP域名xxx.com或者10.100.11.5，通过本地host文件域名解析，找到对应IP服务器安装nginx；

nginx反向代理接受客户机请求，找到server_name为浏览器访问域名xxx.com或者10.100.11.5的server节点，根据proxy_pass对应的http路径，将请求转发到对应的upstream tomcatserverl上。

进一步的，nginx提供的负载均衡策略包括内置策略和扩展策略，本实施例中采用的是内置策略的加权轮询。根据不同服务器不同的处理能力，给每个服务器分配不同的权值，根据不同的权值将不同的服务器分配到对应的服务器上，当请求数量变大时，每个服务处理请求的数量之比会趋向于权重之比。在Nginx加权轮询算法中，每个节点都有3个权重的变量，分别为Weight、currentWeight和effectiveWeight，其中，Weight表示配置的权重，根据配置文件初始化每个服务器节点的权重；currentWeight表示节点的当前权重，其初始化时是配置的权重，随后会不断变更；effectiveWeight表示有效的权重，初始值为配置的权重，在通讯过程中发现节点异常，则将effectiveWeight的值减1，之后再次选择本节点，调用成功一次则将effectiveWeight的值加1，直至其恢复到初始值大小，该参数主要用于做降权。

内置策略的加权轮询的实现逻辑如下：

轮询所有节点，计算当前状态下所有的节点的effectiveWeight之和作为totalWeight；

更新每个节点的currentWeight：

currentWeight＝currentWeight+effectiveWeight

选择所有节点中currentWeight最大的一个节点作为选中节点；

对选中节点再次更新currentWeight：

currentWeight＝currentWeight--totalWeight

客户端为能够向用户提供本地服务的程序，且能够存储token，浏览器通过html5的localStorage(局部存储器)特性把token存储于本地存储，后续用户访问电力营销管理系统内部各应用时，电力营销管理系统后台会进行拦截，在客户端请求的header中携带该token并通过API接口去进行身份验证。

本实施例中，步骤2中的token采用会话ID类别，会话ID类别还包括浏览器端token(web_token)、移动端token(mobile_token)和API应用token(api_token)。

具体的，电力管理营销系统的应用场景包括外网场景和内网场景，外网场景还包括外网网厅web、微信公众号和APP，内网场景还包括内网web和大屏。根据电力营销管理系统的应用场景，根据电力管理营销系统的应用场景，本实施例中采用的token包括web_token、mobile_token和api_token；其中，当应用场景为外网网厅web、微信公众号和内网web时采用web_token，应用场景为APP时采用mobile_token，应用场景为大屏时采用api_token。

进一步的，根据以上不同类别，将token进行分层，参照图3的示意，图3为token的分层示意图，本实施例中将token分为4层，包括密码层、会话层、调用层和应用层。其中，密码层用于进行最传统的用户和系统之间约定的数字身份认证，会话层用于在用户登录后的会话生命周期的会话认证，调用层用于用户在会话期间对应用程序接口的调用认证，应用层用于在用户获取了接口访问调用权限后的场景或者身份认证。

在一个多客户端的信息系统里面，不同类别token的产生及应用的内在联系包括，用户输入用户名和用户口令进行一次性认证，在不同的终端里面生成拥有不同生命周期的会话token，客户端会话token从服务端交换生命周期短但曝光频繁的接口访问token，会话token生成和刷新延长interface_token的生存时间，interface_token生成生存周期较短的各应用端对应的token。

基于token的验证是无状态的，后端服务不需要记录token。每个token都是独立的，包括检查其有效性所需的所有数据，并通过声明传达用户信息。服务器唯一的工作就是在成功的登陆请求上签署token，并验证传入的token是否有效。应用中考虑到安全性始终要坚持变化成本高的token不要轻易变化，不轻易变化的token要减少曝光频率，即减少网络传输次数，曝光频率高的token的生存周期要尽量短的原则。

进一步的，步骤3中的全局过滤器能够作用于API网关的所有路由，且无需配置。采用全局过滤器对判断请求是否携带token，实现对权限的统一校验和安全性验证等功能。

步骤5中，电力营销系统整个架构采用微服务，基于整体业务功能划分包括客户模块和合同模块，因此微服务包括客户模块微服务和合同模块微服务，微服务模块均为后端提供的服务API，前端服务来调用时候都统一到网关入口。

参照图4的示意，本发明还提出了一种基于电力营销管理系统统一认证的验证系统，上述验证方法能够基于该系统实现，基于电力营销管理系统统一认证的验证系统包括：客户端、API网关、API接口、应用程序服务和数据库；

其中，用户通过客户端发送请求向API网关发送请求，客户端包括外网网厅web、微信公众号和APP；

API网关与客户端相连接，通过Spring-Cloud-Gateway和nginx实现，其中，API网关基于Spring-Cloud-Gateway框架搭建，并搭配nginx的反向代理和负载均衡功能；

API接口能够验证用户请求中携带的token是否有效，API接口为应用程序服务的接口，API网关为API接口间的路由；

应用程序服务为电力营销管理系统中能够向客户提供的各种服务，通过调用API接口用户能够获取相应的服务，

数据库与应用程序服务相连接，用于存储电力营销管理系统中所有数据的集合，应用程序服务能够从数据库中获取所需的数据并反馈给用户。

名词释义：

API：Application Programming Interface，应用程序接口；

APP：Application，应用程序。

本发明申请人结合说明书附图对本发明的实施示例做了详细的说明与描述，但是本领域技术人员应该理解，以上实施示例仅为本发明的优选实施方案，详尽的说明只是为了帮助读者更好地理解本发明精神，而并非对本发明保护范围的限制，相反，任何基于本发明的发明精神所作的任何改进或修饰都应当落在本发明的保护范围之内。

Claims (10)

1.一种基于电力营销管理系统统一认证的验证方法，其特征在于，包括以下步骤：

步骤1，电力营销管理系统用户通过客户端向API网关发送请求；

步骤2，API网关根据接收到的请求判断其是否需要认证；

步骤3，若判断为需要认证，则API网关通过全局过滤器判断请求是否携带token；

步骤4，若请求未携带token则认证失败，若请求携带token则通过API接口验证请求携带的token是否有效；

步骤5，若请求携带的token无效则认证失败，若请求携带的token有效则认证成功，获取用户id并将其放入请求头部，用于电力营销管理系统的微服务调用；

步骤6，当用户登出时，客户端销毁token。

2.根据权利要求1所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

用户通过客户端向API网关发送请求的场景包括：PC端内网用户通过web向API网关发送请求，PC端外网用户通过前置机转内网向API网关发送请求，APP用户通过VPN向API网关发送请求，微信公众号用户通过前置机转换内网向API网关发送请求。

3.根据权利要求1或2所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

API网关通过Spring Cloud Gateway和nginx实现，其中，API网关基于Spring CloudGateway框架搭建，搭配nginx的反向代理和负载均衡功能。

4.根据权利要求3所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

判断请求是否需要认证还包括：通过请求携带的url判断是否为登录请求，若接收到的为登录请求则无需认证，否则需要进行认证。

5.根据权利要求4所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

当API网关接收到的请求为登录请求时，用户通过客户端的登录界面输入对应的登录凭据后进行登录认证。

6.根据权利要求5所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

所述登录认证包括：

通过API接口进行身份验证，验证通过后，获取该用户的参数，结合参数信息系统给该用户分发一个token并返回给客户端，当用户登录并发送对系统内部各应用的访问请求时，均携带该用户对应的token。

7.根据权利要求5所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

所述参数包括括用户名、密码和用户id。

8.根据权利要求1所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

步骤2中的token为会话ID类别token，会话ID类别token还包括浏览器端token、移动端token和API应用token。

9.根据权利要求8所述的基于电力营销管理系统统一认证的验证方法，其特征在于，

用户携带的token根据电力管理营销系统的应用场景决定，当应用场景为外网网厅web、微信公众号和内网web时采用web_token，应用场景为APP时采用mobile_token，应用场景为大屏时采用api_token。

10.一种基于电力营销管理系统统一认证的验证系统，其特征在于，包括：客户端、API网关、API接口、应用程序服务和数据库；

用户通过客户端发送请求向API网关发送请求；

API网关与客户端相连接，通过Spring-Cloud-Gateway和nginx实现，；

API接口能够验证用户请求中携带的token是否有效，API接口为应用程序服务的接口，API网关为API接口间的路由；

应用程序服务为电力营销管理系统中能够向客户提供的各种服务，通过调用API接口用户能够获取相应的服务，

数据库与应用程序服务相连接，用于存储电力营销管理系统中所有数据的集合，应用程序服务能够从数据库中获取所需的数据并反馈给用户。

Images