CN112600817A - 前端应用请求接口时的签名认证方法 - Google Patents

Abstract

本发明公开了一种前端应用请求接口时的签名认证方法，包括：获取当前请求的请求行request_line；对所述请求行request_line进行加密；对加密结果进行编码；对编码结果进行urlcode编码，即可得出签名结果。本发明通过将所有的http请求进行网关鉴权，也即在前端应用向服务端发起http请求的中间增加一个网关鉴权，从而避免每一个请求都需要携带token所带来的弊端。这样不仅提高了验证效率，也增强了安全性。

Description

前端应用请求接口时的签名认证方法

技术领域

本发明涉及web前端应用技术领域，特别是一种前端应用请求接口时的签名认证方法。

背景技术

20世纪初Web基本上就是文档的浏览而已。既然只是浏览，作为服务器，不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的http请求，就是请求加响应。

但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，就面临一个问题，那就是要管理会话，必须记住哪些人登录系统，哪些人往自己的购物车中放商品，也就是说必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的。所以当时的解决办法就是给客户端发一个会话标识(session id)，每个客户端收到的都不一样，每次发起HTTP请求的时候，把这个字符串给一并传递给服务端，这样就能区分了。

这种方式的弊端是每个人只需要保存自己的session id，而服务器要保存所有人的session id。如果访问服务器多了，就得由成千上万，甚至几十万个。这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力。

后来有个叫Memcached的提出了一种解决方案就是把session id集中存储到一个地方，所有的机器都来访问这个地方的数据，这样就不用复制了，但是增加了单点失败的可能性，要是那个负责session的机器挂了，所有人都得重新登录一遍。

于是有人就一直在思考，为什么要保存session呢，只让每个客户端去保存就可以了。可是如果不保存这些session id，怎么验证客户端发给服务端的session id的确是客户端生成的呢？

解决方案就是例如用户A已经登录了系统，服务端就给用户A发一个令牌(token)，里边包含了用户A的user id，下一次用户A再次通过http请求访问我的时候，把这个token通过http header传递给服务端就可以了。

通常情况下，在前端应用中，当发起http请求时，为了验证请求参数的合法性，一般是通过在header当中添加token参数。通过账号和密码登录成功，服务端生成一个token(比如：32位不重复的随机字符串)。服务端把该token和用户id保存到数据库(SQLServer或Redis)或者Session中，然后把token值返回给前端。前端应用可以将token保存在localStorage中。

每次发起http请求时，将保存在localStorage的token值通过header参数传递给后端接口，从而进行鉴权该请求接口是否是合法请求。

这种鉴权方式可以实现合法性验证，但也有弊端。验证信息如果存在数据库中，每次都要根据token查用户id，增加了数据库的开销。验证信息如果存在session中，则增大了服务器端存储的压力。token一旦被截取，就很容易进行跨站请求伪造。

发明内容

为解决现有技术中存在的问题，本发明的目的是提供一种前端应用请求接口时的签名认证方法，本发明使用网关在每次请求时就开始进行鉴权，这样就避免了每次发起http请求时，都在header中带上token。

为实现上述目的，本发明采用的技术方案是：一种前端应用请求接口时的签名认证方法，包括以下步骤：

步骤S10、获取当前请求的请求行request_line；

步骤S20、对所述请求行request_line进行加密；

步骤S30、对加密结果进行编码；

步骤S40、对编码结果进行urlcode编码，即可得出签名结果。

作为本发明的进一步改进，所述步骤S10具体包括以下步骤：

步骤S11、在前端应用的http.js文件中加入拦截器，在所述拦截器中，通过config参数获取当前请求的url；

步骤S12、获取浏览器当前时间，使用js时间对象new Date()获取浏览器当前时间，并使用toUTCString进行格式转换；

步骤S13、删除发起请求时的代理配置字段，得到request_line_name；

步骤S14、根据步骤S13中得到的requset_line_name，拼接出当前请求的request_line；

步骤S15、步骤S12获取到的当前时间以及当前具体的请求方式，然后根据步骤S14中得到的requset_line，拼接出当前请求的request_line_string。

作为本发明的进一步改进，所述步骤S20中使用hmac_sha256算法对所述请求行request_line进行加密，具体包括以下步骤：

步骤S21、首先引入CryptoJS包，该CryptoJS包内置hmac_sha256函数；

步骤S22、向步骤S21中的hmac_sha256函数传递request_line_string和access_key两个参数，对request_line进行加密。

作为本发明的进一步改进，所述步骤S30中，使用base64对加密结果进行编码，具体包括以下步骤：

步骤S31、定义toBase64常量；

步骤S32、使用CryptoJS.enc.Base64.stringify()函数对步骤S20中得到的加密结果进行编码，得到一个44位的字符串，将该结果赋值给步骤S31中的toBase64常量。

作为本发明的进一步改进，所述步骤S40具体包括以下步骤：

步骤S41、定义变量signature；

步骤S42、使用encodeURIComponent()函数对步骤S30得到的结果进行urlcode编码，从而得到一个50位的字符串，将该字符串赋值给步骤步骤S41中定义的变量signature，即可得出签名结果。

本发明通过将所有的http请求进行网关鉴权，也即在前端应用向服务端发起http请求的中间增加一个网关鉴权，从而避免每一个请求都需要携带token所带来的弊端。这样不仅提高了验证效率，也增强了安全性。

本发明的有益效果是：

1、不用每次前端应用向服务端发起请求时都需要在header中传递token；

2、提高了前端应用向服务端发起请求的安全性，避免了token被截取的可能性，提高了安全性；

3、减轻了服务端对前端应用发起请求的合法性验证的压力，不用对每个接口请求都进行验证，而是在之前就已经进行了鉴权，提高了验证效率。

附图说明

图1为本发明实施例中使用token进行鉴权流程框图；

图2为本发明实施例中使用网关进行鉴权的架构图；

图3为本发明实施例中在前端应用中使用网关鉴权计算签名流程框图。

具体实施方式

下面结合附图对本发明的实施例进行详细说明。

实施例

如图1-图3所示，一种前端应用请求接口时的签名认证方法，包括以下步骤：

1、判断得出当前请求的request_line：通过判断当前环境是生产环境还是开发环境以及当前是哪个代理模块的http请求，从而得出当前请求的request_line；具体包括：

步骤一：在前端应用的http.js文件中，需要加入拦截器。在拦截器中，通过config参数获取当前请求的url；

步骤二：获取浏览器当前时间。使用js时间对象new Date()获取浏览器当前时间，并使用toUTCString进行格式转换；

步骤三：删除发起请求时的代理配置字段，得到request_line_name。这一步需要区分是开发环境还是测试环境，需要根据开发环境和测试环境进行不同的判断处理；并且在这一步中需要根据各个不同的模块代理进行判断处理，从而才能获取到当前的request_line_name；

步骤四：根据不同的模块，拼接出当前请求的request_line。根据不同的模块，然后根据步骤三中得到的requset_line_name，拼接出当前请求的request_line；

步骤五：拼接出当前请求的request_line_string。根据步骤二获取到的当前时间以及当前具体的请求方式(例如：get、post、delete等)，然后根据步骤四中得到的requset_line，拼接出当前请求的request_line_string。

2、使用hmac_sha256算法计算加密：使用CryptoJS.HmacSHA256()函数，传递request_line_string和access_key两个参数，对步骤1中得到的request_line进行加密；具体包括：

步骤一：首先引入CryptoJS包，该包内置hmac_sha256函数；

步骤二：向步骤一中的hmac_sha256函数传递request_line_string和access_key两个参数，对request_line进行加密。

3、使用base64对加密结果进行编码：使用CryptoJS.enc.Base64.stringify()函数将步骤1中得出的结果传递到该函数中，从而得到一个44位的编码结果；具体包括：

步骤一：首先定义一个常量，例如toBase64这样的常量；

步骤二：使用CryptoJS.enc.Base64.stringify()函数对步骤2中得到的加密结果进行编码，得到一个44位的字符串；将该结果赋值给步骤一中的常量。

4、对编码结果进行urlcode编码：使用js环境自带函数encodeURIComponent()对步骤2得到的结果进行urlcode编码，从而得到一个50位的字符串；具体包括：

步骤一：定义一个类似signature这样的变量；

步骤二：使用js环境自带函数encodeURIComponent()对步骤3得到的结果进行urlcode编码，从而得到一个50位的字符串；将该字符串赋值给步骤一中定义的变量。

经过以上4个步骤，在步骤4中即可得出签名结果。得出签名结果后，接下来对如何使用该签名结果进行具体描述：

步骤一：将步骤4中计算得出的signature，拼接到`hmacaccesskey＝"${accesskey}",algorithm＝"HMAC_SHA256",headers＝"x-date request-line",signature＝"${signature}"`字符串中；

步骤二：在header中添加Authorization参数，将步骤一中得到的字符串赋值给该参数；

步骤三：在header中添加x-date参数，将步骤1的步骤二中得到的时间赋值给该参数。注意：这里不能直接添加date参数，否则浏览器会报错；

步骤四：根据当前请求是get、post、put、patch、delete请求方式的不同，分别进行不同的处理。如果是get请求，就不需要对body进行加密，直接对request_line进行签名；如果是post、put、patch、delete，这3种请求方式可以一起处理，需要在header中添加Digest参数，将`SHA_256＝${post_body_to_urlcode}`赋值给该参数。

以上所述实施例仅表达了本发明的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (5)

1.一种前端应用请求接口时的签名认证方法，其特征在于，包括以下步骤：

步骤S10、获取当前请求的请求行request_line；

步骤S20、对所述请求行request_line进行加密；

步骤S30、对加密结果进行编码；

步骤S40、对编码结果进行urlcode编码，即可得出签名结果。

2.根据权利要求1所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤S10具体包括以下步骤：

步骤S11、在前端应用的http.js文件中加入拦截器，在所述拦截器中，通过config参数获取当前请求的url；

步骤S12、获取浏览器当前时间，使用js时间对象new Date()获取浏览器当前时间，并使用toUTCString进行格式转换；

步骤S13、删除发起请求时的代理配置字段，得到request_line_name；

步骤S14、根据步骤S13中得到的requset_line_name，拼接出当前请求的request_line；

步骤S15、步骤S12获取到的当前时间以及当前具体的请求方式，然后根据步骤S14中得到的requset_line，拼接出当前请求的request_line_string。

3.根据权利要求2所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤S20中使用hmac_sha256算法对所述请求行request_line进行加密，具体包括以下步骤：

步骤S21、首先引入CryptoJS包，该CryptoJS包内置hmac_sha256函数；

步骤S22、向步骤S21中的hmac_sha256函数传递request_line_string和access_key两个参数，对request_line进行加密。

4.根据权利要求1或3所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤S30中，使用base64对加密结果进行编码，具体包括以下步骤：

步骤S31、定义toBase64常量；

步骤S32、使用CryptoJS.enc.Base64.stringify()函数对步骤S20中得到的加密结果进行编码，得到一个44位的字符串，将该结果赋值给步骤S31中的toBase64常量。

5.根据权利要求4所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤S40具体包括以下步骤：

步骤S41、定义变量signature；

步骤S42、使用encodeURIComponent()函数对步骤S30得到的结果进行urlcode编码，从而得到一个50位的字符串，将该字符串赋值给步骤步骤S41中定义的变量signature，即可得出签名结果。

Images