集群权限认证的方法、客户端、服务端及存储介质与流程

1.本技术涉及信息技术安全领域，尤其涉及一种集群权限认证的方法、客户端、服务端及存储介质。


背景技术：

2.随着互联网的兴起，出现了越来越多的应用系统提供服务，应用系统在面对大流量访问时，也需要采取集群部署进行分流处理提高并发性。如何鉴别一个请求属于哪个用户，拥有哪些权限，如何快速刷新登录用户的权限，以及传输泄漏后如何保证有效的拦截，都是当前方案面临的诸多挑战。


技术实现要素：

3.本技术实施例提供了一种集群权限认证的方法、客户端、服务端及存储介质，用于降低了令牌token泄漏后的风险，同时提升集群鉴权能力、降低网络消耗。
4.本技术第一方面提供一种集群权限认证的方法，可以包括：
5.客户端向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的，所述用户令牌、所述当前时间戳、所述目标请求令牌和所述当前url用于获取目标业务数据；
6.所述客户端接收所述服务端发送的所述目标业务数据。
7.本技术第二方面提供一种集群权限认证的方法，可以包括：
8.服务端接收客户端发起的目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的；
9.在所述当前时间戳在有效请求时间允许范围的情况下，所述服务端根据所述当前时间戳和预设加密规则，生成当前请求令牌；
10.在所述目标请求令牌和所述当前请求令牌相同的情况下，所述服务端获取所述用户令牌对应的用户信息；
11.所述服务端根据所述用户令牌对应的当前用户信息，从缓存中心获取所述当前用户所属的所有角色对应的url权限列表；
12.若所述当前url在所述url权限列表中，则所述服务端根据所述目标业务数据请求获取目标业务数据；
13.所述服务端向所述客户端发送所述目标业务数据。
14.本技术第三方面提供一种客户端，可以包括：
15.发起模块，用于向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的，所述用户令牌、所述当前时间戳、所述目标请求令牌和所述当前url用于获取目标
业务数据；
16.接收模块，用于接收所述服务端发送的所述目标业务数据。
17.本技术第四方面提供一种客户端，可以包括：
18.接收模块，用于接收客户端发起的目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的；
19.处理模块，用于在所述当前时间戳在有效请求时间允许范围的情况下，根据所述当前时间戳和预设加密规则，生成当前请求令牌；在所述目标请求令牌和所述当前请求令牌相同的情况下，获取所述用户令牌对应的用户信息；根据所述用户令牌对应的当前用户信息，从缓存中心获取所述当前用户所属的所有角色对应的url权限列表；若所述当前url在所述url权限列表中，则根据所述目标业务数据请求获取目标业务数据；
20.发送模块，用于向所述客户端发送所述目标业务数据。
21.本技术又一方面提供一种客户端，可以包括：
22.存储有可执行程序代码的存储器；
23.与所述存储器耦合的收发器；
24.所述收发器用于对应执行如本技术第一方面所述的方法。
25.本技术又一方面提供一种客户端，可以包括：
26.存储有可执行程序代码的存储器；
27.与所述存储器耦合的收发器和处理器；
28.所述收发器和所述处理器用于对应执行如本技术第二方面所述的方法。
29.本技术实施例又一方面提供一种计算机可读存储介质，包括指令，当其在处理器上运行时，使得处理器执行本技术第一方面或第二方面所述的方法。
30.本技术实施例又一方面公开一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行本技术第一方面或第二方面所述的方法。
31.本技术实施例又一方面公开一种应用发布平台，所述应用发布平台用于发布计算机程序产品，其中，当所述计算机程序产品在计算机上运行时，使得所述计算机执行本技术第一方面或第二方面所述的方法。
32.从以上技术方案可以看出，本技术实施例具有以下优点：
33.在本技术实施例中，客户端向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的，所述用户令牌、所述当前时间戳、所述目标请求令牌和所述当前url用于获取目标业务数据；客户端接收所述服务端发送的所述目标业务数据。用于降低了令牌token泄漏后的风险，同时提升集群鉴权能力、降低网络消耗。
附图说明
34.为了更清楚地说明本技术实施例技术方案，下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，还可以根据这些附图获得其它的附图。
35.图1为本技术实施例所应用的系统架构图；
36.图2为本技术实施例中集群权限认证的方法的一个实施例示意图；
37.图3为登录存储、请求鉴权的改进方案流程图；
38.图4为本技术角色权限变更及校验的流程图；
39.图5为本技术实施例中客户端的一个实施例示意图；
40.图6为本技术实施例中服务端的一个实施例示意图；
41.图7为本技术实施例中客户端的另一个实施例示意图；
42.图8为本技术实施例中服务端的另一个实施例示意图。
具体实施方式
43.本技术实施例提供了一种集群权限认证的方法、客户端、服务端及存储介质，用于降低了令牌token泄漏后的风险，同时提升集群鉴权能力、降低网络消耗。
44.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，都应当属于本技术保护的范围。
45.下面先对本技术所涉及的一些术语做一个简要的说明，如下所示：
46.jwt是缩写，全拼则是json web tokens，是目前流行的跨域认证解决方案，一种基于json的、用于在网络上声明某种主张的令牌(token)。jwt验证方式是将用户信息通过加密生成token，每次请求服务端只需要使用保存的密钥验证token的正确性，不用再保存任何session数据了，进而服务端变得无状态，容易实现拓展。
47.token在计算机身份认证中是令牌(临时)的意思，在词法分析中是标记的意思。一般作为邀请、登录系统使用。
48.随着互联网的兴起，出现了越来越多的应用系统提供服务，应用系统在面对大流量访问时，也需要采取集群部署进行分流处理提高并发性。如何鉴别一个请求属于哪个用户，拥有哪些权限，目前已知的权限认证方案如下：
49.基于cookie的会话标识，客户端登录成功后，服务端绑定会话跟cookie信息；客户端后续请求带上cookie信息，服务端根据cookie识别具体的用户。
50.基于jwt，客户端登录成功后。服务端返回用户信息+过期时间等加密后的token串，客户端后续请求带上token，服务端解密token识别用户，再从统一缓存存储中心获取用户的具体权限信息。
51.其他token认证，类似jwt，只是没有携带过期时间、用户信息，服务端无需解密。
52.但是，现有的技术方案在面对大流量的客户端请求时，会面临各种缺陷：
53.1、基于cookie的方案，会出现部分客户端不支持cookie无法使用的情况；如果没有使用统一会话管理中心进行管理时，集群系统就没法识别出具体的登录用户；同时也会面临cookie数据伪造的情况；目前cookie方案已经被行业逐渐遗弃。
54.2、基于jwt方案，虽然解决了统一会话识别、集群等问题，但增加了网络传输信息加大了网络损耗，且实际业务使用时还是需要统一权限中心去存取请求用户的其他信息及权限列表，不可能将这些信息都放到jwt信息中；同时jwt的单独固定失效时间，也不利于对用户进行快速失效、退出标记；最关键的还是token泄漏后，服务端无法识别是否合法请求。
55.3、其他token方案，也面临token泄漏后的非法请求无法识别问题。
56.4、授权成功后，用户对应角色权限变更后，现有的方案中如果没有根据角色权限变更，实时修改已登录用户的权限信息，会导致过期的权限还能被使用的安全风险。
57.基于现有认证方案的缺乏集群支持、token泄漏风险、无法快速刷新权限等缺点，本技术基于集群系统的权限认证为出发点，设计双令牌三阶段权限验证方案，提供了一种更加安全、高效的权限认证方法。如图1所示，为本技术实施例所应用的系统架构图。在图1所示中，主要描述了服务集群部署的架构思路。本技术引入统一的缓存中心(cache center，hc)来快速存取权限信息，其中，hc可以使用业界常见缓存中间件如redis等。整体流程为当登录成功后存储token关联用户，角色关联权限的信息；当后续请求的时候从hc取出token对应的用户及权限信息进行鉴权；当角色权限变更的时候重新更新hc中对应角色的信息。
58.本技术引入了hc可以解决现有部分方案中碰到的集群部署会话不共享的问题；同时本技术传输的token信息都比较简短(例如通常双令牌不到80个字符即可)，不像现有jwt方案那样携带很多信息(正例如常业务至少超过500个字符)，进而降低了传输过程中的网络消耗；而且存储token还能达到随时作废token的作用，进而也提升了安全性。
59.如图2所示，为本技术实施例中集群权限认证的方法的一个实施例示意图，可以包括：
60.201、客户端向服务端发送登录请求，所述登录请求包括当前用户的登录信息。
61.所述服务端接收所述客户端发送的登录请求，所述登录请求包括当前用户的登录信息。
62.可选的，所述登录信息包括用户信息、角色权限信息。
63.示例性的，如图3所示，为登录存储、请求鉴权的改进方案流程图。在图3所示中，客户端要请求获取服务端接口数据，首先要先进行登录认证，这里登录的具体方案有很多，例如：用户名+密码+验证码登录，手机号+验证码登录，三方授权登录等，都可以达到登录的效果，本技术对具体登录方案不做限定。
64.202、所述服务端验证所述登录信息，在验证通过的情况下，生成关于所述当前用户的用户令牌。
65.客户端携带登录信息向服务端发起目标业务数据请求后(该目标业务数据请求的url(uniform resource locator，统一资源定位系统)要排除掉权限过滤)，服务端校验当前登录信息是否合法、正确，如果校验不通过，则提示错误信息给客户端；如果校验通过，则服务端生成当前用户对应的唯一令牌token(t1，也就是用户令牌)，并将用户信息、权限存储到缓存中心hc，并将t1返回给客户端。
66.具体存储细节如图4的第一个节点所示：存储t1与用户信息的关联，其中用户信息含当前用户所拥有的所有角色标识(id)；同时缓存中心中如果没有对应的角色标识信息，则要查询出角色标识对应的url权限信息，存储角色id对应的url权限列表。本技术用角色与权限的关联来存储，区别于传统的直接将权限信息与token信息进行关联，主要是考虑后续角色权限变更后，可以快速的更新角色对应的所有用户的权限。
67.203、所述服务端向所述客户端发送关于所述当前用户的用户令牌，所述用户令牌用于所述客户端发起目标业务数据请求。
68.所述客户端接收所述服务端发送的关于所述当前用户的用户令牌。
69.可以理解的是，步骤201-203，可以认为是请求登录阶段b1：客户端登录成功后，服务端保存当前登录用户的用户信息、角色权限信息，然后生成并返回用户令牌(token)(t1)给客户端，客户端本地可以存起来。
70.204、客户端向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的。
71.服务端接收客户端发起的目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的。
72.可选的，所述目标请求令牌是根据所述当前时间戳和所述用户令牌生成的。
73.可以理解的是，在客户端向服务端发起目标业务数据请求之前，客户端可以根据当前时间戳生成目标请求令牌，或根据当前时间戳和用户令牌生成目标请求令牌，然后，再向服务端发起目标业务数据请求，该目标业务数据请求携带该目标请求令牌。不管是客户端根据当前时间戳生成目标请求令牌，还是根据当前时间戳和用户令牌生成目标请求令牌，都属于根据当前时间戳和约定的加密规则生成目标请求令牌。
74.示例性的，客户端登录成功后，获取到了t1，要进行本地存储，后续的目标业务数据请求都要带上这个令牌值进行用户身份的识别。由于传输过程中，可能会泄漏t1，导致t1在长有效时间内被非法利用的可能。因此本技术设计了双令牌机制：发起目标业务数据请求的时候同时还要传t2(目标请求令牌)、当前时间戳(s1)和当前url，其中s1是为了生成t2，t2的生成规则可以按照不同客户端进行定制，但要加上s1。比如：t2＝md5(s1+t1+固定密钥)，就是按规则拼接完字符串后，再进行md5等不可逆加密算法进行加密得到新字符串token(t2)。
75.本技术的加密规则中，使用当前时间戳可以有效控制请求的时效性，降低泄漏风险；使用t1可以避免不同用户的t2一样；使用固定密钥跟拼接后再进行md5不可逆加密，都是为了增加算法猜测难度，降低风险。
76.205、在所述当前时间戳在有效请求时间允许范围的情况下，所述服务端根据所述当前时间戳和预设加密规则，生成当前请求令牌。
77.可以理解的是，服务端接收到客户端的目标业务数据请求后，首先判断目标业务数据请求的url是否需要授权校验，如果不需要则继续进行后续的业务数据获取；如果需要校验，则从目标业务数据请求中获取t1、t2、s1，其中，s1只是为了根据加密规则计算出应该生成的字符串z1，如果t1、t2、s1有一个为空，都说明请求非法。
78.示例性的，服务端首先判断请求时效性：根据目标业务数据请求携带的当前时间戳s1判断目标业务数据请求时间是否在有效请求时间允许范围(自定义)内，比如服务端时间s2-s1》3秒，或者s2-s1《0秒就判断该目标业务数据请求非法，相当于一个目标业务数据请求允许的有效时间为0-3秒(含传输延时时间)，如果不符合则返回错误信息给客户端，如果符合则继续下一步。
79.206、在所述目标请求令牌和所述当前请求令牌相同的情况下，所述服务端获取所述用户令牌对应的用户信息。
80.示例性的，服务端判断第二阶段为t2正确性判断：根据目标业务数据请求的s1及
约定的加密规则，生成当前请求令牌z1(例如：z1＝md5(s1+t1+固定密钥))，判断当前请求令牌z1是否跟目标业务数据请求携带的目标请求令牌t2相等，由于使用约定的加密规则，所以按理来说当前请求令牌z1要等于目标请求令牌t2，不相等说明目标业务数据请求的数据被伪造，相等则继续下一步。
81.207、所述服务端根据所述用户令牌对应的当前用户信息，从缓存中心获取所述当前用户所属的所有角色对应的url权限列表。
82.208、若所述当前url在所述url权限列表中，则所述服务端根据所述目标业务数据请求获取目标业务数据。
83.示例性的，服务端判断第三阶段为校验url权限：获取用户令牌t1对应的用户信息，如果获取到用户登录信息且还未过期的，则继续从缓存中心获取用户所属的所有角色对应的url权限，进行并集，得到所有角色对应的url权限列表，然后判断目标业务数据请求url是否在角色url权限列表中，如果存在则继续后续的业务数据获取。
84.可以看到服务端通过上面的三步，主要通过用户令牌t1和目标请求令牌t2的两个令牌，结合目标业务数据请求时效来判断请求的合法性，通过服务端的3个阶段校验，完成权限校验流程，能有效解决token泄漏风险。例如现有的方案只传t1，且没控制请求时效，则t1被窃取后，在t1登录有效时间内(非请求时效，通常都半小时以上)，都会被窃取者利用以伪造数据。本技术通过双令牌三阶段认证，假如泄漏了t1，窃取者并不能通过校验，即使t2、s1也泄漏了，能利用的时间也就几秒而已，可见本技术技术方案相比于目前常见的权限系统有很大的安全提升。
85.可以理解的是，步骤204-208可以认为是请求校验阶段b2：
86.步骤b2-1：客户端后续目标业务数据请求除了带上b1返回的token(t1)，还要带上当前时间戳(s1)及约定的加密规则加密后的token(t2)传给服务端；服务端接收到请求信息后，先校验s1是否在合理的有效请求时间允许范围内，进而判断是否继续进行后续校验。
87.步骤b2-2：服务端按照约定的加密规则加密出新的字符串z1，将z1与请求的t2比较是否相等，由于使用约定的加密规则，所以按理来说z1要等于t2，不相等说明目标业务数据请求的数据被伪造，相等则继续下一步。
88.步骤b2-3：合法性校验成功后，服务端就可以继续根据t1从统一权限缓存中心hc获取当前用户信息及权限列表，根据当前用户信息可以判断登录的时效性，根据权限列表可以判断是否拥有目标请求url的权限，如果该步鉴权通过，则可以获取业务数据信息。
89.209、所述服务端向所述客户端发送所述目标业务数据。
90.所述客户端接收所述服务端发送的目标业务数据。
91.可选的，所述方法还可以包括：所述服务端在检测到角色权限变更后，同步更新缓存中心获取所述当前用户所属的所有角色对应的url权限列表。
92.可以理解的是，该实现方式相当于权限变更阶段：当角色权限变更后，刷新hc中对应角色的权限缓存信息，就可以快速、及时的刷新该角色关联的所有用户的权限。
93.示例性的，权限变更阶段快速刷新的改进方案的具体步骤如下所示：
94.如图4所示，为本技术角色权限变更及校验的流程图。在图4所示中，主要描述权限变更快速刷新的改进方案流程。hc中存储了角色标识(identity，id)对应的url权限列表，当角色对应的url权限被修改后，服务端实时更新hc中的对应角色的权限列表，这样后续新
的请求过来的时候，在校验的第三阶段，从hc获取权限列表的时候就是当前用户所能拥有的最新的权限，避免了旧权限还能使用的问题。
95.在现有技术方案中，用户登录后将权限绑定在t1上面，如果角色权限变更，要找到当前角色关联的所有用户，然后如果没有存用户跟t1的关联，则无法更新当前角色已登录用户的权限，只能等重新登录后再进行权限的变更；如果有存储，则要遍历所有t1进行漫长的更新操作，特别是用户量多的情况，更无法及时更新权限，导致过期的权限被使用的风险。本技术是在第三阶段校验的时候，通过角色中转进行关联，从而能够快速、及时的获取到最新的权限集。
96.本技术基于集群系统的权限认证为出发点，设计双令牌三阶段权限验证方案，提供了一种更加安全、高效的权限认证方法。通过上述三个改进点的细节描述，可以看到本技术能够提升了集群鉴权能力、降低了网络消耗；并且降低了token泄漏后的风险；同时解决了权限无法快速、及时更新的问题。即有对登录、校验存储阶段跟请求、鉴权阶段的方案改进；也有对权限变更阶段快速刷新的方案改进。
97.如图5所示，为本技术实施例中客户端的一个实施例示意图，可以包括：
98.发起模块501，用于向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的，所述用户令牌、所述当前时间戳、所述目标请求令牌和所述当前url用于获取目标业务数据；
99.接收模块502，用于接收所述服务端发送的所述目标业务数据。
100.可选的，发起模块501，还用于向所述服务端发送登录请求，所述登录请求包括当前用户的登录信息；
101.接收模块502，还用于接收所述服务端发送的关于所述当前用户的用户令牌。
102.可选的，所述目标请求令牌是根据所述当前时间戳和所述用户令牌生成的。
103.如图6所示，为本技术实施例中服务端的一个实施例示意图，可以包括：
104.接收模块601，用于接收客户端发起的目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的；
105.处理模块602，用于在所述当前时间戳在有效请求时间允许范围的情况下，根据所述当前时间戳和预设加密规则，生成当前请求令牌；在所述目标请求令牌和所述当前请求令牌相同的情况下，获取所述用户令牌对应的用户信息；根据所述用户令牌对应的当前用户信息，从缓存中心获取所述当前用户所属的所有角色对应的url权限列表；若所述当前url在所述url权限列表中，则根据所述目标业务数据请求获取目标业务数据；
106.发送模块603，用于向所述客户端发送所述目标业务数据。
107.可选的，接收模块601，还用于接收所述客户端发送的登录请求，所述登录请求包括当前用户的登录信息；
108.处理模块602，还用于验证所述登录信息，在验证通过的情况下，生成关于所述当前用户的用户令牌；
109.发送模块603，还用于向所述客户端发送关于所述当前用户的用户令牌，所述用户令牌用于所述客户端发起目标业务数据请求。
110.可选的，处理模块602，还用于在检测到角色权限变更后，同步更新缓存中心获取所述当前用户所属的所有角色对应的url权限列表。
111.可选的，所述目标请求令牌是根据所述当前时间戳和所述用户令牌生成的。
112.如图7所示，为本技术实施例中客户端的另一个实施例示意图，可以包括：
113.存储有可执行程序代码的存储器701；
114.与存储器701耦合的收发器702；
115.收发器702，用于向服务端发起目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的，所述用户令牌、所述当前时间戳、所述目标请求令牌和所述当前url用于获取目标业务数据；接收所述服务端发送的所述目标业务数据。
116.可选的，收发器702，还用于向所述服务端发送登录请求，所述登录请求包括当前用户的登录信息；接收所述服务端发送的关于所述当前用户的用户令牌。
117.可选的，所述目标请求令牌是根据所述当前时间戳和所述用户令牌生成的。
118.如图8所示，为本技术实施例中服务端的另一个实施例示意图，可以包括：
119.存储有可执行程序代码的存储器801；
120.与存储器801耦合的收发器802和处理器803；
121.收发器802，用于接收客户端发起的目标业务数据请求，所述目标业务数据请求包括用户令牌、当前时间戳、目标请求令牌和当前url，所述目标请求令牌是根据所述当前时间戳生成的；
122.处理器803，用于在所述当前时间戳在有效请求时间允许范围的情况下，根据所述当前时间戳和预设加密规则，生成当前请求令牌；在所述目标请求令牌和所述当前请求令牌相同的情况下，获取所述用户令牌对应的用户信息；根据所述用户令牌对应的当前用户信息，从缓存中心获取所述当前用户所属的所有角色对应的url权限列表；若所述当前url在所述url权限列表中，则根据所述目标业务数据请求获取目标业务数据；
123.收发器802，用于向所述客户端发送所述目标业务数据。
124.可选的，收发器802，还用于接收所述客户端发送的登录请求，所述登录请求包括当前用户的登录信息；
125.处理器803，还用于验证所述登录信息，在验证通过的情况下，生成关于所述当前用户的用户令牌；
126.收发器802，还用于向所述客户端发送关于所述当前用户的用户令牌，所述用户令牌用于所述客户端发起目标业务数据请求。
127.可选的，处理器803，还用于在检测到角色权限变更后，同步更新缓存中心获取所述当前用户所属的所有角色对应的url权限列表。
128.可选的，所述目标请求令牌是根据所述当前时间戳和所述用户令牌生成的。
129.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质
中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
130.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
131.在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
132.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
133.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
134.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
135.以上所述，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。