一种请求拦截方法及装置与流程

本申请涉及信息数据处理技术领域，更具体地说，涉及一种请求拦截方法及装置。

背景技术：

当用户在操作界面上操作某个控件时即向服务器发送了相关的请求，如查询请求，修改资料请求等。服务器在接收到用户发送的请求后，会对用户发送的请求进行各验证项目的验证，如用户身份验证、用户权限验证、超时验证等，只有各验证项目都通过时该请求才合法，该请求才会被执行；否则拦截该请求即拒绝执行该请求，并向用户返回某一验证项目对应的失败原因。

当前，服务器返回失败原因的方法为：当某个验证项目的验证失败时，服务器会调用与该验证项目对应的处理验证失败情况的处理模块，该处理模块将与该验证项目对应的失败原因添加到返回消息中，从而将包括了失败原因的返回消息返回给用户。

针对上述请求拦截方法，在软件开发设计时，需针对每个验证项目单独配置一个处理验证失败情况的处理模块，也即针对每个拦截原因配置各自对应的处理模块，并对每个处理模块分别进行具体的定义以保证每个处理模块能够实现添加各自对应的失败原因到返回消息中，该开发设计方式较为复杂，造成软件开发和维护成本高。

技术实现要素：

有鉴于此，本申请提供一种请求拦截方法及装置，以解决现有技术开发设计方式较为复杂，造成软件开发和维护成本高的问题。

为了实现上述目的，现提出的方案如下：

一种请求拦截方法，所述方法包括：

接收用户请求；

对所述用户请求对应的验证项目依次进行验证；

当任一验证项目的验证失败时，获得与所述验证项目对应的失败原因，并对所述失败原因进行存储；

调用统一处理模块，以使所述统一处理模块获取存储的所述失败原因并生成包含所述失败原因的返回信息。

一种请求拦截装置，所述装置包括：

接收模块，用于接收用户请求；

验证模块，用于对所述用户请求所对应的验证项目依次进行验证，并当任一验证项目的验证失败时，获得与所述验证项目对应的失败原因，并对所述失败原因进行存储；

统一处理模块，用于获取存储的所述失败原因并生成包含所述失败原因的返回信息。

本申请方案中，对于接收到的用户请求，对用户请求所对应的各验证项目依次进行验证，当任一验证项目的验证失败时，获得与所述验证项目对应的失败原因，并对所述失败原因进行存储，进而调用统一处理模块去获取存储的失败原因并生成包含失败原因的返回消息。可见，本申请中在某一验证项目的验证失败时对失败原因进行存储，后续调用一统一处理模块统一去执行获取存储失败原因以及根据失败原因生成返回消息的操作。对应到软件开发设计来说，由于存储了失败原因，所以只需设置定义一个统一处理模块，其能够去获取存储的任一验证项目对应的失败原因，以及能够根据失败原因生成包括失败原因的返回消息；与传统的请求拦截方法相比，该方案无需再针对每个失败原因配置各自对应的处理模块，并对每个处理模块进行具体的定义，该开发设计方式简单，降低了软件开发和维护的成本，同时提高了软件的质量。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种请求拦截方法的流程图；

图2为本申请另一实施例公开的调用统一处理模块方法的流程图；

图3为本申请实施例公开的对验证项目的验证方法的流程图；

图4为本申请实施例公开的一种请求拦截装置的组成框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供一种请求拦截方法，如图1所示，该方法包括：

s100、接收用户请求。

具体的，服务器在接收到用户请求后，查看配置文件struts.xml以确定服务器是否配置了拦截机制，即确定服务器中是否配置了拦截器，当确定配置有拦截器后，按照拦截器栈内定义的拦截器执行顺序，调用拦截器执行验证及拦截处理。通常，服务器中设置有两个拦截器，包括自定义拦截器和系统默认拦截器，本申请实施例提供的请求拦截方法可为针对自定义拦截器设置。

s101、对所述用户请求对应的验证项目依次进行验证。

其中，按照各验证项目的验证顺序对各验证项目依次进行验证，验证项目包括但不限于：用户权限验证项目、令牌信息token验证项目，超时验证项目等，当所有验证项目的验证都通过时，放行该用户请求，向用户返回针对用户具体请求内容的执行结果。

s102、当任一验证项目的验证失败时，获得与所述验证项目对应的失败原因，并对所述失败原因进行存储。

其中，当任一验证项目的验证失败时，则拦截该用户请求，首先要获得该验证项目验证失败的原因，并存储该失败原因。其中，每个验证项目都有其各自对应的失败原因。

优选地，对所述失败原因进行存储具体为：将失败原因存储到预设的复用接口中，针对struts2开源框架来说，该预设的复用接口为与用户请求对应的actioncontext中，即将失败原因存储到与用户请求对应的actioncontext中。由于actioncontext是基于用户请求而创建的线程中有效，当服务器拒绝访问(或放行执行请求)，返回拦截的拒绝原因(或返回请求的执行结果)后，将自动失效。

s103、调用统一处理模块，以使所述统一处理模块获取存储的所述失败原因并生成包含所述失败原因的返回信息。

其中，为了调用统一处理模块，本申请实施例中优选地，采用chain链跳转的方式跳转到统一处理模块，即调用统一处理模块，具体过程如2所示，包括：

s1031、获得统一拦截标识。

具体的，以用户请求对应的超时验证项目为例，如代码段一所示。

其中，第2行表示获取令牌信息token的过期时间，第4行表示判断令牌时间是否过期，如果超时则执行拦截。首先获得验证失败的原因，并将失败原因存储到复用接口中，如第5行所示，将map类成员添加到与用户请求对应的actioncontext中，map的key为“dataresult”，map的value为"超时连接，请重新登录！"，“超时连接，请重新登录！”即为超时验证项目对应的失败原因。可以理解，其他验证项目对应的拦截原因也采用上述方式存储到与用户请求对应的actioncontext里，如此即实现了对同一个接口的复用。第6行表示获得统一拦截标识“appresult”，不同的拦截原因都使用了该统一拦截标识。

s1032、确定与所述统一拦截标识对应的统一处理模块。

具体的，在配置文件struts.xml中配置统一拦截标识为chain链跳转方式，并配置跳转到的处理模块为统一处理模块，如代码段二所示。可以理解，本发明的请求拦截方法为服务器执行各程序模块中代码段实现的方法，将代码段一作为是对验证项目进行验证的验证模块的一部分，服务器先是调用了验证模块进行执行，并在某一验证项目的验证失败时，通过获得的统一拦截标识跳转到另一程序模块并执行另一程序模块，在此即调用了统一处理模块执行。

其中，第2行表示采用"chain"对统一拦截标识“appresult”进行action链跳转配置。第3行表示跳转到的统一处理模块为“authprocessingaction”。

s1033、调用所述统一处理模块，以使所述统一处理模块获取存储的拦截原因并根据所述拦截原因和预设的返回消息格式生成返回信息，所述返回信息包括所述拦截原因。

其中，统一处理模块包括如下的代码段三。

其中，第一行至第七行表示声明变量“jsondataresult”，第十行表示从复用接口actioncontext内获取"dataresult"，其包含了失败原因，第十一行表示将“dataresult”赋值给前述声明的变量“jsondataresult”，后续，通过变量“jsondataresult”将失败原因返回给用户。具体的，在生成返回信息时，根据预设的返回消息格式生成返回消息。其中，第12行的"logjson"标志即表示开始执行生成返回消息的处理，而预设的返回消息格式配置在配置文件struts-common.xml中，“struts-common.xml”配置文件对返回消息的返回格式的配置如代码段四所示。

其中，第四行表示为返回消息配置的格式为json格式，生成的json格式的返回消息为第五行配置的“jsondataresult”中包含的内容的集合。最终，服务器将json格式的返回消息返回给用户，完成拦截，至此，拦截的具体原因也返回给了用户。

上述实施例中，将任一验证项目对应的失败原因存储到了与用户请求对应的复用接口中，并利用链跳转方式进行跳转，调用统一处理模块去获取复用接口中存储的失败原因并生成包括失败原因的返回消息返回给用户，可见，针对不同的失败原因复用同一接口传递信息，无需针对每种验证失败的情况单独配置处理模块，降低了开发和维护的成本，使程序体系更清晰，提升了软件质量，具备较高的应用价值。

在本申请另一实施例中，接收到用户请求后，对用户请求的来源进行判断以确定用户请求的来源是移动终端还是网页。其中，确定用户请求的来源为移动终端，对用户请求进行移动终端对应的验证拦截处理，确定用户请求的来源为网页时，对用户请求进行网页对应的验证拦截处理。可以理解，移动终端和电脑基于的硬件环境是不同的，如对于银行来说，其运行在移动终端中的银行客户端与基于电脑浏览器的网上银行的程序开发架构是不同的，所以服务器需要针对移动终端和网页分别开发一套与它们各自程序架构对应的验证拦截程序，但从本质的处理方式上来说，两套验证拦截程序的验证拦截流程是相同的。

其中，对用户请求的来源进行判断以确定用户请求的来源是移动终端还是网页包括：获取用户请求的动作类，具体的，通过代码invocation.getaction().getclass()获取用户请求的动作类，并判断该动作类是否为移动终端对应的动作类，若是，则确定用户请求来源是移动终端，若否，则确定用户请求来源是网页。

具体的，确定所述用户请求的来源为移动终端，所述调用统一处理模块获取存储的所述拦截原因包括：

获得移动终端对应的统一拦截标识，确定所述移动终端对应的统一拦截标识对应的统一处理模块，调用所述移动终端对应的统一拦截标识对应的统一处理模块，以使所述移动终端对应的统一拦截标识对应的统一处理模块获取存储的所述拦截原因，根据所述拦截原因和预设的移动终端对应的返回消息格式生成返回信息。

其中，移动终端对应的统一拦截标识即为上述实施例中记载的“appresult”，预设的移动终端对应的返回消息格式即为上述实施例中记载的json格式。

确定所述用户请求的来源为网页，所述调用统一处理模块获取存储的所述拦截原因包括：

获得网页对应的统一拦截标识，确定所述网页对应的统一拦截标识对应的统一处理模块，调用所述网页对应的统一拦截标识对应的统一处理模块，以使所述网页对应的统一拦截标识对应的统一处理模块获取存储的所述拦截原因，根据所述拦截原因和预设的网页对应的返回消息格式生成返回消息。

其中，网页对应的统一拦截标识例如设置为“computerresult”，预设的网页对应的返回消息格式可设置为页面的格式。

上述实施例中，对接收到的用户请求进行来源的判断，以对不同来源的用户请求进行差异化处理，如此实现了在同一个服务器上对不同来源的用户请求进行处理，实现了对服务器的复用，提高了服务器的利用率。

在本申请另一实施例中，采用了服务器缓存与数据库结合的方式来对验证项目进行校验，其中，验证项目包括令牌信息验证项目和超时验证项目，如图3所示，对所述令牌信息验证项目和超时验证项目进行验证包括：

s300、判断服务器缓存中是否存储所述用户对应的令牌信息，若服务器缓存中未存储所述用户对应的令牌信息，则执行步骤s301，若服务器缓存中存储所述用户对应的令牌信息，则执行步骤s302。

s301、查询数据库中是否存储所述用户对应的令牌信息，若数据库中未存储所述用户对应的令牌信息，则确定所述令牌信息验证项目的验证失败，若数据库中存储所述用户对应的令牌信息，则执行步骤s303。

s302、根据服务器缓存中存储的所述用户对应的令牌信息的过期时间，判断服务器缓存中存储的所述用户对应的令牌信息是否过期，若过期，则执行步骤s303，若未过期，则执行步骤s304。

s303、查询数据库中存储的所述用户对应的令牌信息的过期时间，判断数据库中存储的所述用户对应的令牌信息是否过期，若数据库中存储的所述用户对应的令牌信息过期，则确定所述超时验证项目的验证失败，若数据库中存储的所述用户对应的令牌信息未过期，则执行步骤s307。

s304、统计所述用户发送的用户请求的次数，并判断所述次数是否小于预设次数。

其中，统计的次数是针对同一个用户发送的请求进行的统计。

s305、若所述次数小于预设次数，则将服务器缓存中存储的所述用户对应的令牌信息的过期时间延长预设时间。

s306、若所述次数等于预设次数，则将服务器缓存中存储的最新的所述用户对应的令牌信息的过期时间更新到所述数据库中，并将所述统计的所述用户发送的用户请求的次数清零。

s307、将所述数据库中存储的所述用户对应的令牌信息的过期时间延长所述预设时间，并将延长后的过期时间更新到服务器缓存中。

上述实施例中，服务器缓存和数据库中存储有各验证项目对应的验证信息，其中包括用户的令牌信息token、token的超期时间。在进行验证时，首先查询服务器缓存内是否存在该用户的token，如果缓存内不存在token，再查询数据库内是否存在该用户的token，如此提高了验证信息查询的速度，同时降低了数据库查询率，减少了数据库的io次数。

当在查询到存储该用户的token后，进一步校验该token是否失效，由于用户请求可能来自手机等移动终端，所以用户在使用应用程序时可能会走动，由此可能导致为用户提供信号的移动信号基站变更，而移动信号基站的变更，可能会导致后台服务器集群对应的服务节点产生变化，即为用户提供服务的服务器发生了变更，变更后的当前服务器内的缓存中存储的用户的token的过期时间可能不是最新的过期时间，所以为了确保用户的合法请求不被拦截，在判断缓存内token过期后，进一步判断数据库内该用户的token是否过期，如果数据库内的token也过期，才确定为超时验证项目的验证失败，对用户请求进行拦截，否则放行执行用户请求。上述结合缓存和数据库的双重过期时间验证机制，进一步降低了发生错误拦截的可能性，提高了验证的识别准确率。

进一步的，当每次用户请求通过校验被认证为合法请求后，针对该用户进行请求次数计数，当用户的请求次数少于预设次数如5次时，每次将缓存内该用户的token失效时间向后延长预设时间如15分钟；而当用户的请求次数累计到5次时，将缓存内该用户的最新的token失效时间更新到数据库中，同时将针对该用户的请求次数清零，当再接收到该用户的请求时，重新开始计数，如此进一步提高了缓存与数据库的一致性，使校验识别更加准确。

本申请实施例还提供一种请求拦截装置，如图4所示，该装置包括：

接收模块400，用于接收用户请求；

验证模块401，用于对所述用户请求所对应的验证项目依次进行验证，并当任一验证项目的验证失败时，获得与所述验证项目对应的失败原因，并对所述失败原因进行存储；

统一处理模块402，用于获取存储的所述失败原因并生成包含所述失败原因的返回信息。

其中，所述验证模块401对所述失败原因进行存储具体包括：将所述失败原因存储到预设的复用接口中。针对struts2开源框架来说，该预设的复用接口为与所述请求对应的actioncontext。

其中，验证模块401在验证失败时会获得一个与验证失败对应的统一拦截标识，服务器通过查询配置文件确定统一拦截标记对应的跳转方式，以及跳转到的统一处理模块，如此服务器调用确定的统一处理模块402，以使所述统一处理模块402获取存储的所述失败原因并根据所述失败原因和预设的返回消息格式生成返回信息，所述返回信息包括所述失败原因。

可选地，本申请实施例还包括请求源确定单元，用于确定所述用户请求的来源。当确定用户请求的来源为移动终端时，调用与移动终端对应的验证、处理模块对用户请求进行验证。当确定用户请求的来源为网页时，调用与网页对应的验证、处理模块对用户请求进行验证。

其中，验证模块401利用服务器缓存与数据库结合的方式来对验证项目进行校验的原理与上述实施例相同，在此不再赘述。

最后，还需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。