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

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

【技术实现步骤摘要】
前端应用请求接口时的签名认证方法
本专利技术涉及web前端应用
，特别是一种前端应用请求接口时的签名认证方法。
技术介绍
20世纪初Web基本上就是文档的浏览而已。既然只是浏览，作为服务器，不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的http请求，就是请求加响应。但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，就面临一个问题，那就是要管理会话，必须记住哪些人登录系统，哪些人往自己的购物车中放商品，也就是说必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的。所以当时的解决办法就是给客户端发一个会话标识(sessionid)，每个客户端收到的都不一样，每次发起HTTP请求的时候，把这个字符串给一并传递给服务端，这样就能区分了。这种方式的弊端是每个人只需要保存自己的sessionid，而服务器要保存所有人的sessionid。如果访问服务器多了，就得由成千上万，甚至几十万个。这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力。后来有个叫Memcached的提出了一种解决方案就是把sessionid集中存储到一个地方，所有的机器都来访问这个地方的数据，这样就不用复制了，但是增加了单点失败的可能性，要是那个负责session的机器挂了，所有人都得重新登录一遍。于是有人就一直在思考，为什么要保存session呢，只让每个客户端去保存就可以了。可是如果不保存这些sessionid，怎么验证客户端发给服务端的sessionid的确是客户端生成的呢？解决方案就是例如用户A已经登录了系统，服务端就给用户A发一个令牌(token)，里边包含了用户A的userid，下一次用户A再次通过http请求访问我的时候，把这个token通过httpheader传递给服务端就可以了。通常情况下，在前端应用中，当发起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时间对象newDate()获取浏览器当前时间，并使用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文件中，需要加入拦截器。在拦截器中，通过co本文档来自技高网...

【技术保护点】
1.一种前端应用请求接口时的签名认证方法，其特征在于，包括以下步骤：/n步骤S10、获取当前请求的请求行request_line；/n步骤S20、对所述请求行request_line进行加密；/n步骤S30、对加密结果进行编码；/n步骤S40、对编码结果进行urlcode编码，即可得出签名结果。/n

【技术特征摘要】
1.一种前端应用请求接口时的签名认证方法，其特征在于，包括以下步骤：
步骤S10、获取当前请求的请求行request_line；
步骤S20、对所述请求行request_line进行加密；
步骤S30、对加密结果进行编码；
步骤S40、对编码结果进行urlcode编码，即可得出签名结果。


2.根据权利要求1所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤S10具体包括以下步骤：
步骤S11、在前端应用的http.js文件中加入拦截器，在所述拦截器中，通过config参数获取当前请求的url；
步骤S12、获取浏览器当前时间，使用js时间对象newDate()获取浏览器当前时间，并使用toUTCString进行格式转换；
步骤S13、删除发起请求时的代理配置字段，得到request_line_name；
步骤S14、根据步骤S13中得到的requset_line_name，拼接出当前请求的request_line；
步骤S15、步骤S12获取到的当前时间以及当前具体的请求方式，然后根据步骤S14中得到的requset_line，拼接出当前请求的request_line_string。


3.根据权利要求2所述的前端应用请求接口时的签名认证方法，其特征在于，所述步骤...

【专利技术属性】
技术研发人员：刘强，
申请(专利权)人：四川长虹电器股份有限公司，
类型：发明
国别省市：四川;51