CN113535427A - 处理请求消息的方法、装置、系统、终端及存储介质 - Google Patents

Abstract

本发明提供一种处理请求消息的方法、装置、系统、终端及存储介质。本发明实施例提供的一种处理请求消息的方法包括：接收用户端的请求消息；判断请求消息为登录请求消息还是业务请求消息；在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。本发明不但可以应用于涉及至少二种不同用户类型的管理平台，以实现同一管理平台对不同用户类型的数据请求的统一处理，而且可以在提高数据处理的效率的同时确保数据处理过程中验证信息的安全性。

Description

处理请求消息的方法、装置、系统、终端及存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种处理请求消息的方法、装置、系统、终端及存储介质。

背景技术

对于互联网管理平台来说，通常使用同一管理平台的用户群体会非常多。比如对于电商平台来说，通常会涉及管理员、商户、客户、仓库物流、供应链和客服等多种用户群体。在实际应用中，各种用户群体在同一管理平台中处理相关业务时都会涉及登录验证。

现有技术中，通常都是通过各个用户群体的用户端独立去实现登录验证，不但数据处理的效率低、成本高、不方便扩展，而且登录验证信息本身在网络传输过程中也存在一定的安全风险。因此，如何在提高数据处理效率的同时保证信息的安全是亟需解决的问题。

发明内容

本发明的一个目的在于，提供一种处理请求消息的方法、装置、系统、终端及存储介质。

本发明实施例提供的一种处理请求消息的方法包括：接收用户端的请求消息；判断请求消息为登录请求消息还是业务请求消息；在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

可选地，对电子令牌进行令牌验证包括对解密令牌进行令牌验证；方法包括：判断请求消息是否携带电子令牌；在请求消息携带电子令牌时，对请求消息携带的电子令牌进行解密而得到解密令牌。

可选地，电子令牌包括JWT。

可选地，登录请求消息包括用户类型、登录账号及其对应的登录密码；对登录请求消息进行登录验证包括：获取关于用户类型的账户数据，账户数据包括用户账号信息及其对应的用户密码信息；基于用户账号信息及其对应的用户密码信息对登录账号和登录密码进行登录验证。

可选地，该方法还包括：在登录验证失败时，发送登录失败消息至用户端。

可选地，该方法还包括：在令牌验证失败时，发送未登录提示消息至用户端。

可选地，业务请求消息包括用户类型；响应业务请求消息包括基于用户类型响应业务请求消息。

本发明实施例提供的一种处理请求消息的装置包括：接收模块，用于接收用户端的请求消息；第一判断模块，用于判断请求消息为登录请求消息还是业务请求消息；第一处理模块，用于在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；第二处理模块，用于在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

可选地，该装置还包括第二判断模块和第三处理模块；第二判断模块用于判断请求消息是否携带电子令牌；第三处理模块用于在请求消息携带电子令牌时，对请求消息携带的电子令牌进行解密而得到解密令牌；第二处理模块用于对解密令牌进行令牌验证。

本发明实施例提供的一种处理请求消息的系统包括：用户端，其适于发送请求消息；服务器，其包括第一处理器和第一存储器，第一存储器存储有可在第一处理器上运行的计算机程序，计算机程序被第一处理器执行时实现本发明实施例提供的处理请求消息的方法。

本发明实施例提供的一种终端包括：第二处理器；第二存储器，其存储有可在第二处理器上运行的计算机程序；其中，计算机程序被第二处理器执行时实现本发明实施例提供的处理请求消息的方法。

本发明实施例提供的一种存储介质存储有计算机程序，该计算机程序被执行时本发明实施例提供的处理请求消息的方法。

与现有技术相比，本发明实施例的技术方案具有有益效果。

例如，本发明实施例提供的技术方案可以应用于涉及至少二种不同用户类型(即用户群体)的管理平台。并且，可以实现同一管理平台对不同用户类型的数据请求的统一处理，不但有效地提高了数据处理的效率，而且方便了平台对不同用户的管理和维护。

又例如，采用本发明实施例提供的技术方案可以使得同一用户在与同一管理平台进行数据交互时，只需完成一次登录验证，无需在每次触发业务请求后都进行登录验证，不但提高了数据处理的效率，而且避免了在每次触发业务请求时都携带验证信息而产生的安全风险。

又例如，采用本发明实施例提供的技术方案可以使得同一管理平台中不同的用户类型通过同一类型的用户端与该管理平台进行数据交互，不但便于平台的管理维护，而且减少了同一管理平台需要针对不同的用户类型开发不同的用户端所带来的高昂成本。

附图说明

图1是本发明实施例中处理请求消息的方法的一种流程示意图；

图2是本发明实施例中处理请求消息的方法的另一种流程示意图；

图3是本发明实施例中处理请求消息的方法的一种实现示意图；

图4是本发明实施例中处理请求消息的装置的一种原理框图；

图5是本发明实施例中处理请求消息的装置的另一种原理框图。

具体实施方式

现有技术中，同一管理平台的各种用户群体在处理相关业务时都会涉及登录验证，并且各个用户群体都是独立去实现登录验证，不但使得数据处理的效率低、成本高、不方便扩展，而且登录验证信息本身在网络传输过程中也存在一定的安全风险。

不同于现有技术，本发明提供一种处理请求消息的方法、装置、系统、终端及存储介质。本发明实施例提供的一种处理请求消息的方法包括：接收用户端的请求消息；判断请求消息为登录请求消息还是业务请求消息；在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

相较于现有技术，本发明不但可以应用于涉及至少二种不同用户类型的管理平台，以实现同一管理平台对不同用户类型的数据请求的统一处理，而且可以在提高数据处理的效率的同时确保数据处理过程中验证信息的安全性。

为使本发明的目的、特征和有益效果能够更为明显易懂，下面结合附图对本发明的具体实施例进行详细说明。可以理解的是，以下所描述的具体实施例仅仅用于解释本发明，而非是对本发明的限定。并且，以下可能省略不同实施例中相同、类似的部件的描述以及现有技术部件、特征、效果等的描述。此外，为了便于描述，附图中仅示出了与本发明实施例相关的部分而非全部结构。并且，附图中可能使用不同的标号指代不同实施例中相同、类似的部件。

图1是本发明实施例中处理请求消息的方法的一种流程示意图。

参照图1，本发明实施例提供的一种处理请求消息的方法10可以包括如下步骤：

S11，接收用户端的请求消息；

S12，判断请求消息为登录请求消息还是业务请求消息；

S13，在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供用户端触发业务请求消息时调用；

S14，在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

如前所述，本发明实施例提供的技术方案可以应用于涉及至少二种不同用户类型的管理平台。并且，采用本发明实施例提供的技术方案可以实现同一管理平台对不同用户类型的数据请求的统一处理。

在一些实施例中，管理平台可以包括购物平台。并且，购物平台会涉及包括管理员、商户、消费客户、仓库物流、供应链和客服等在内的多种用户群体。其中，每一种用户群体对应于一种用户类型。

在具体实施中，每一种用户类型的用户群体均使用用户端与管理平台进行数据交互。

在一些实施例中，不同的用户类型对应的用户群体均可以采用同一种用户端与管理平台进行数据交互。

例如，不同的用户类型所对应的用户群体均可以采用同一种购物应用程序(即Application，简称App)与购物平台进行数据交互。

在具体实施中，可以通过用户端向管理平台发送涉及登录或者业务处理的请求消息。

在步骤S11的具体实施中，可以接收来自用户端的请求消息。

在步骤S12的具体实施中，可以判断请求消息为登录请求消息还是业务请求消息。

具体而言，可以判断请求消息中包括与登录请求消息相关的登录信息还是包括与业务请求消息相关的业务信息。

在具体实施中，与登录请求消息相关的登录信息可以包括登录账号及其对应的登录密码。

例如，在一些实施例中，触发用户端以发送请求消息的用户群体可以是消费客户。在此情形下，登录账号及其对应的登录密码可以分别为消费客户的登录账号及登录密码。

当请求消息中包括与登录请求消息相关的登录信息时，可以确定该请求消息为登录请求消息。

在确定请求消息为登录请求消息时，可以执行步骤S13。

在步骤S13的具体实施中，可以对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供用户端触发业务请求消息时调用。

在一些实施例中，登录请求消息可以包括用户类型、登录账号及其对应的登录密码。

相应地，步骤S13中所述的对登录请求消息进行登录验证可以包括：

S131，获取关于用户类型的账户数据；其中，账户数据包括用户账号信息及其对应的用户密码信息；

S132，基于用户账号信息及其对应的用户密码信息对登录账号和登录密码进行登录验证。

在具体实施中，管理平台都可以创建自己的数据库，用于存储和管理不同用户类型的账户数据。并且，针对不同的用户类型，在数据库中可以分别设置不同的账户数据表，以分别存储和管理不同用户类型的账户数据。

例如，可以在购物平台的数据库中设置管理员账户数据表、商户账户数据表、消费客户账户数据表、仓库物流账户数据表、供应链账户数据表和客服账户数据表等，以用于分别存储和管理管理员、商户、消费客户、仓库物流、供应链和客服的账户数据。

在一些实施例中，可以从数据库中获取与登录请求消息中携带的用户类型相关的账户数据表，并且基于该账户数据表获取相应的账户数据。

在另一些实施例中，还可以基于数据库创建数据模型，并且可以针对不同的用户类型，在数据模型中分别设置不同的账户数据模型类，以分别存储和管理不同用户类型的账户数据。在此情形下，可以从数据模型中获取与登录请求消息中携带的用户类型相关的账户数据模型类，并且基于该账户数据模型类获取相应的账户数据。

在具体实施中，账户数据可以包括用户账号信息及其对应的用户密码信息。由此，可以基于用户账号信息及其对应的用户密码信息对登录账号和登录密码进行登录验证。

当在账户数据中没有找到与登录账号和登录密码匹配的用户账号信息及其对应的用户密码信息时，可以确定登录验证失败。

在一些实施例中，当登录验证失败时，可以发送登录失败消息至用户端，以便于用户端核实登录账号及其对应的登录密码是否正确。

当在账户数据中找到与登录账号和登录密码匹配的用户账号信息及其对应的用户密码信息时，可以确定登录验证通过。

在具体实施中，当登录验证通过时可以生成电子令牌，并且将电子令牌返回至用户端，以供用户端触发业务请求消息时调用。

在一些实施例中，电子令牌可以包括JWT(Json web token)。

在具体实施中，生成JWT可以采用本领域任意已知的常规技术手段实现，此处不作限定。

在具体实施中，发送请求消息的用户端适于接收并且存储该电子令牌，并且在触发业务请求消息时调用该电子令牌。具体而言，可以在触发业务请求消息时将该电子令牌包装于业务请求消息，以使业务请求消息携带该电子令牌。

在具体实施中，当用户端接收到电子令牌时，可以确定已完成登录。

可以理解的是，电子令牌是与登录用户，例如登录账号，相关联的。并且，一个登录账号在完成一次登录验证后具有一个电子令牌。在该登录账号退出登录之前，均可以携带该电子令牌触发业务请求消息。

如此，可以使得同一用户在与同一管理平台进行数据交互时，只需完成一次登录验证即可携带电子令牌触发一次或者多次业务请求消息，并且无需在每次触发业务请求时都携带登录账号及其对应的登录密码进行登录验证(即无需在每次触发业务请求时都进行登录验证)。

在具体实施中，与业务请求消息相关的业务信息可以与用户类型相关。

例如，当用户类型涉及消费客户时，与业务请求消息相关的业务信息可以包括提交订单、支付订单、确认收货等。当用户类型涉及商户时，与业务请求消息相关的业务信息可以包括发布产品、产品下架、接收订单等。

当请求消息中包括与业务请求消息相关的业务信息时，可以确定该请求消息为业务请求消息。

在确定请求消息为业务请求消息时，可以执行步骤S14。

在步骤S14的具体实施中，可以对业务请求消息中携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

在一些实施例中，电子令牌可以包括JWT。

在具体实施中，对JWT进行令牌验证可以采用本领域中任意已知的常规技术手段实现，此处不作限定。

可以理解的是，JWT具有有效期。在对JWT进行令牌验证时，不仅需要对JWT本身携带的有效数据信息进行验证，而且需要对JWT的有效期进行一并验证。

在具体实施中，当JWT本身携带的有效数据信息验证通过，而JWT的有效期验证不通过时，可以确定令牌验证失败。在此情形下，可以使得相应登录账号退出登录。

一些实施例中，当令牌验证失败时，可以发送未登录提示消息至用户端，以便于提示用户端当前为未登录状态。

在一些实施例中，步骤S14所述的对电子令牌进行令牌验证可以包括对解密令牌进行令牌验证。

相应地，该处理请求消息的方法10可以包括：

S15，判断请求消息是否包括电子令牌；

S16，在请求消息包括电子令牌时，对电子令牌进行解密而得到解密令牌。

在具体实施中，对电子令牌进行解密而得到解密令牌、以及对解密令牌进行令牌验证均可以采用本领域中任意已知的常规技术手段实现，此处不作限定。

在具体实施中，当令牌验证通过时，可以响应该业务请求消息。

在具体实施中，可以基于业务请求消息中包括的业务信息响应该业务请求消息。

例如，业务请求消息中包括关于发布产品的业务信息。则可以响应于该业务请求消息而进行发布产品的操作。

在一些实施例中，业务请求消息还可以包括用户类型。在此情形下，可以基于用户类型响应业务请求消息。

在具体实施中，管理平台都可以创建自己的数据库，以用于存储和管理不同用户类型的业务数据。并且，针对不同的用户类型，可以在数据库中分别设置不同的业务数据表，以分别存储和管理不同用户类型的业务数据。

例如，可以在购物平台的数据库中设置管理员业务数据表、商户业务数据表、消费客户业务数据表、仓库物流业务数据表、供应链业务数据表和客服业务数据表等，以用于分别存储和管理管理员、商户、消费客户、仓库物流、供应链和客服的业务数据。

在一些实施例中，可以从数据库中获取与用户类型相关的业务数据表，并且基于该业务数据表获取相应的业务数据。

在另一些实施例中，还可以基于数据库创建数据模型，并且可以针对不同的用户类型，在数据模型中分别创建不同的业务数据模型类，以分别存储和管理不同用户类型的业务数据。在此情形下，可以从数据模型中获取与用户类型相关的业务数据模型类，并且基于该业务数据模型类获取相应的业务数据。

在具体实施中，业务数据还与具体的业务类型相关。

例如，业务类型包括发布产品。则与发布产品相关的业务数据可以包括产品名称、产品价格、产品库存数量等。

在具体实施中，业务类型可以包括于业务请求消息的业务信息中。

例如，业务信息包括发布产品，则其中包括的业务类型就是发布产品。

在具体实施中，可以基于业务数据响应业务请求消息。

例如，业务请求消息中包括关于商户发布产品的业务信息。则可以获取与商户发布产品相关的业务数据，例如可以是产品名称、产品价格、产品库存数量等。

在具体实施中，可以响应于该业务请求消息而进行产品名称、产品价格、产品库存数量等的发布操作。

图2是本发明实施例中处理请求消息的方法的另一种流程示意图。

具体而言，该处理请求消息的方法20可以包括如下步骤：

S21，接收用户端的请求消息；

S22，判断请求消息是否包括电子令牌；

S23，在请求消息包括电子令牌时，对电子令牌进行解密而得到解密令牌；

S24，判断请求消息为登录请求消息还是业务请求消息；

S25，在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供用户端触发业务请求消息时调用；

S26，在请求消息为业务请求消息时，对解密令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

关于步骤S21的具体实施可以参照处理请求消息的方法10中的步骤S11。

关于步骤S22的具体实施可以参照处理请求消息的方法10中的步骤S15。

关于步骤S23的具体实施可以参照处理请求消息的方法10中的步骤S16。

关于步骤S24的具体实施可以参照处理请求消息的方法10中的步骤S12。

关于步骤S25的具体实施可以参照处理请求消息的方法10中的步骤S13。

关于步骤S26的具体实施可以参照处理请求消息的方法10中的步骤S14。

与图1所示的处理请求消息的方法10不同的是，图2所示的处理请求消息的方法10，在步骤21和步骤24之间增加了步骤S22和步骤S23。

图3是本发明实施例中处理请求消息的方法的一种实现示意图。

图3所示实施例示意了管理平台仅涉及商户和客户(例如可以是消费客户)的情形。

在管理平台仅涉及商户和客户时，请求消息可以包括商户登录请求消息、客户登录请求消息、商户业务请求消息和客户业务请求消息。

在本发明中，可以结合图3所示实现示意图来理解图2所示的处理请求消息的方法20。

在具体实施中，步骤S22和步骤S23可以通过设置网关实现。其具体实施过程可以本领域中任意已知的常规技术手段实现，此处不作限定。

在具体实施中，步骤S24可以通过设置路由实现。其具体实施过程可以本领域中任意已知的常规技术手段实现，此处不作限定。

在具体实施中，步骤S25所述的对登录请求消息进行登录验证可以通过设置控制器实现。其具体实施过程可以本领域中任意已知的常规技术手段实现，此处不作限定。

在具体实施中，步骤S26所述的对解密令牌进行令牌验证可以通过设置中间件实现。其具体实施过程可以本领域中任意已知的常规技术手段实现，此处不作限定。

本发明实施例还提供一种处理请求消息的装置。

图4是本发明实施例中处理请求消息的装置的一种原理框图。

参照图4，该处理请求消息的装置30包括：

接收模块31，用于接收用户端的请求消息；

第一判断模块32，用于判断请求消息为登录请求消息还是业务请求消息；

第一处理模块33，用于在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；

第二处理模块34，用于在请求消息为业务请求消息时，对业务请求消息携带的电子令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

可以理解的是，本发明实施例提供的处理请求消息的装置30可以基于本发明实施例提供的处理请求消息的方法10而实施。并且，该处理请求消息的装置30中各模块所实现的功能以及各模块之间的关系也可以参考前述关于处理请求消息的方法10的描述，此处不再赘述。

图5是本发明实施例中处理请求消息的装置的另一种原理框图。

参照图5，该处理请求消息的装置40包括：

接收模块41，用于接收用户端的请求消息；

第二判断模块45，用于判断请求消息是否包括电子令牌；

第三处理模块46，用于在请求消息包括电子令牌时，对电子令牌进行解密而得到解密令牌；

第一判断模块42，用于判断请求消息为登录请求消息还是业务请求消息；

第一处理模块43，用于在请求消息为登录请求消息时，对登录请求消息进行登录验证、以及在登录验证通过时生成电子令牌返回至用户端以供触发业务请求消息时调用；

第二处理模块44，用于在请求消息为业务请求消息时，对解密令牌进行令牌验证、以及在令牌验证通过时响应业务请求消息。

可以理解的是，本发明实施例提供的处理请求消息的装置40可以基于本发明实施例提供的处理请求消息的方法20而实施。并且，该处理请求消息的装置40中各模块所实现的功能以及各模块之间的关系也可以参考前述关于处理请求消息的方法20的描述，此处不再赘述。

在具体实施中，接收模块41可以为接收模块31。第一判断模块42可以为第一判断模块32。第一处理模块43可以为第一处理模块33。第二处理模块44可以为第二处理模块34。

本发明实施例还提供一种处理请求消息的系统。

具体而言，该处理请求消息的系统可以包括：

用户端，其适于发送请求消息；

服务器，其包括第一处理器和第一存储器。

其中，第一存储器存储有可在第一处理器上运行的计算机程序，该计算机程序被第一处理器执行时可以实现本发明实施例提供的处理请求消息的方法10、20。

本发明实施例还提供一种终端。

具体而言，该终端包括：

第二处理器；

第二存储器，其存储有可在第二处理器上运行的计算机程序。

其中，该计算机程序被第二处理器执行时可以实现本发明实施例提供的处理请求消息的方法10、20。

在具体实施中，该终端可以是处理请求消息的系统中的服务器。

本发明实施例还提供一种存储介质。

具体而言，该存储介质存储有计算机程序。该计算机程序被执行时可以实现本发明实施例提供的处理请求消息的方法10、20。

在具体实施中，该存储介质可以包括计算机可读存储介质。

在具体实施中，该存储介质可以包括非易失性存储介质或非瞬态存储介质。

在具体实施中，该存储介质可以包括ROM、RAM、磁盘或光盘等。

尽管上文已经描述了具体实施方案，但这些实施方案并非要限制本发明公开的范围，即使仅相对于特定特征描述单个实施方案的情况下也是如此。本发明公开中提供的特征示例意在进行例示，而非限制，除非做出不同表述。在具体实施中，可根据实际需求，在技术上可行的情况下，将一项或者多项从属权利要求的技术特征与独立权利要求的技术特征进行组合，并可通过任何适当的方式而不是仅通过权利要求书中所列举的特定组合来组合来自相应独立权利要求的技术特征。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (12)

1.一种处理请求消息的方法，其特征在于，包括：

接收用户端的请求消息；

判断所述请求消息为登录请求消息还是业务请求消息；

在所述请求消息为所述登录请求消息时，对所述登录请求消息进行登录验证、以及在所述登录验证通过时生成电子令牌返回至所述用户端以供触发所述业务请求消息时调用；

在所述请求消息为所述业务请求消息时，对所述业务请求消息携带的电子令牌进行令牌验证、以及在所述令牌验证通过时响应所述业务请求消息。

2.根据权利要求1所述的方法，其特征在于，所述对所述电子令牌进行令牌验证包括对解密令牌进行令牌验证；所述方法包括：

判断所述请求消息是否携带电子令牌；

在所述请求消息携带电子令牌时，对所述请求消息携带的电子令牌进行解密而得到所述解密令牌。

3.根据权利要求1或2所述的方法，其特征在于，所述电子令牌包括JWT。

4.根据权利要求1所述的方法，其特征在于，所述登录请求消息包括用户类型、登录账号及其对应的登录密码；所述对所述登录请求消息进行登录验证包括：

获取关于所述用户类型的账户数据，所述账户数据包括用户账号信息及其对应的用户密码信息；

基于所述用户账号信息及其对应的所述用户密码信息对所述登录账号和所述登录密码进行所述登录验证。

5.根据权利要求1所述的方法，其特征在于，包括：

在所述登录验证失败时，发送登录失败消息至所述用户端。

6.根据权利要求1所述的方法，其特征在于，包括：

在所述令牌验证失败时，发送未登录提示消息至所述用户端。

7.根据权利要求1所述的方法，其特征在于，所述业务请求消息包括用户类型；所述响应所述业务请求消息包括基于所述用户类型响应所述业务请求消息。

8.一种处理请求消息的装置，其特征在于，包括：

接收模块，用于接收用户端的请求消息；

第一判断模块，用于判断所述请求消息为登录请求消息还是业务请求消息；

第一处理模块，用于在所述请求消息为所述登录请求消息时，对所述登录请求消息进行登录验证、以及在所述登录验证通过时生成电子令牌返回至所述用户端以供触发所述业务请求消息时调用；

第二处理模块，用于在所述请求消息为所述业务请求消息时，对所述业务请求消息携带的电子令牌进行令牌验证、以及在所述令牌验证通过时响应所述业务请求消息。

9.根据权利要求8所述的装置，其特征在于，包括第二判断模块和第三处理模块；所述第二判断模块用于判断所述请求消息是否携带电子令牌；所述第三处理模块用于在所述请求消息携带电子令牌时，对所述请求消息携带的电子令牌进行解密而得到解密令牌；所述第二处理模块用于对所述解密令牌进行令牌验证。

10.一种处理请求消息的系统，其特征在于，包括：

用户端，其适于发送请求消息；

服务器，其包括第一处理器和第一存储器，所述第一存储器存储有可在所述第一处理器上运行的计算机程序，所述计算机程序被所述第一处理器执行时实现如权利要求1至7中任一项所述的方法。

11.一种终端，其特征在于，包括：

第二处理器；

第二存储器，其存储有可在所述第二处理器上运行的计算机程序；

其中，所述计算机程序被所述第二处理器执行时实现如权利要求1至7中任一项所述的方法。

12.一种存储介质，所述存储介质存储有计算机程序，其特征在于，所述计算机程序被执行时实现如权利要求1至7中任一项所述的方法。

Images