CN103139163B - 数据访问方法、服务器和终端 - Google Patents
数据访问方法、服务器和终端 Download PDFInfo
- Publication number
- CN103139163B CN103139163B CN201110388487.1A CN201110388487A CN103139163B CN 103139163 B CN103139163 B CN 103139163B CN 201110388487 A CN201110388487 A CN 201110388487A CN 103139163 B CN103139163 B CN 103139163B
- Authority
- CN
- China
- Prior art keywords
- terminal
- apikey
- request
- server
- dynamic key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本申请提供了一种数据访问方法、服务器和终端,其中,数据访问方法包括:在一次终端通过客户端程序请求使用服务器端的API的过程中,服务器端接收终端发送的使用API的请求,所述请求中包括APIKEY,所述APIKEY由终端根据服务器端发送的动态密钥和终端保存的公钥生成,客户端程序包括除浏览器之外的用于请求服务器端的API的应用程序;服务器端根据所述请求确定终端发送的APIKEY与服务器端的APIKEY一致;服务器端允许终端使用API,并生成新的动态密钥发送给终端在下一次请求中使用。通过本申请,有效保证了APIKEY合法用户使用API的安全。
Description
技术领域
本申请涉及网络技术领域,特别是涉及一种数据访问方法、服务器和终端。
背景技术
随着网络和电子商务的飞速发展,越来越多的服务平台应运而生,这些服务平台为了给使用者提供更多更好的服务,常常需要接入第三方应用。在这种情况下,用户在使用这些平台提供的多样化服务的同时,使用这些应用和服务的安全性也不断受到挑战。
第三方应用与服务平台API(ApplicationProgrammingInterface,应用程序接口)服务器之间的通信安全性是用户使用平台提供的应用和服务的安全性的主要方面。为了保证这种安全性,通常会在提出第三方应用请求时,对请求进行加密。如,淘宝开放平台为了保证第三方应用与淘宝开放平台API服务器之间通信的安全性,防止信息盗用、数据篡改等恶意攻击行为,淘宝开放平台API服务器使用了APIKEY(API签名)的签名机制。
这种签名机制在应用API时,需要通过一个客户端程序(非浏览器程序)向服务器端发送一个APIKEY,在APIKEY获得通过后,才能应用请求的API,并且,该APIKEY将在整个应用过程中一直使用。然而,如果该固定APIKEY在应用API过程中被非合法使用者恶意获取,尤其是在使用移动终端进行无线通信的环境下,则该恶意获取者可以非法无数次的用该APIKEY使用API,进行非法活动,造成APIKEY合法用户的损失。
总之,需要本领域技术人员迫切解决的一个技术问题就是:如何能够保证终端用户访问和应用API的安全性。
发明内容
本申请提供了一种数据访问方法、服务器和终端,以解决现在技术中,终端用户,尤其是通过客户端程序访问和应用API的安全性的问题。
为了解决上述问题,本申请公开了一种数据访问方法,包括:在一次终端通过客户端程序请求使用服务器端的应用程序接口API的过程中,所述服务器端接收所述终端发送的使用所述API的请求,所述请求中包括应用程序接口签名APIKEY,所述APIKEY由所述终端根据所述服务器端发送的动态密钥和所述终端保存的公钥生成,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序;所述服务器端根据所述请求确定所述终端发送的APIKEY与所述服务器端的APIKEY一致;所述服务器端允许所述终端使用所述API,并生成新的动态密钥发送给所述终端在下一次请求中使用。
优选地,所述APIKEY由所述终端根据所述服务器端发送的动态密钥和所述终端保存的公钥生成包括:所述终端根据所述服务器端发送的所述动态密钥、存储的与所述服务器端一致的公钥和/或请求参数,使用加密算法,生成所述APIKEY。
优选地,所述请求还包括所述终端的客户端标识;所述服务器端根据所述请求确定所述终端发送的APIKEY与所述服务器端的APIKEY一致的步骤包括:所述服务器端根据所述客户端标识,获得所述服务器端存储的所述动态密钥;使用与所述终端相同的所述加密算法,根据获得的所述动态密钥生成所述服务器端的APIKEY;判断所述服务器端的APIKEY与所述终端发送的所述APIKEY是否一致;若是,则确定所述终端发送的APIKEY与所述服务器端的APIKEY一致。
优选地,在所述服务器端生成新的动态密钥发送给所述终端在下一次请求中使用的步骤之后,还包括:若所述服务器端向所述终端发送所述新的动态密钥失败,则所述服务器端向所述终端发送错误信息,并在所述错误信息中携带所述新的动态密钥;或者,若所述服务器端向所述终端发送所述新的动态密钥失败,所述服务器端保存生成所述APIKEY的所述动态密钥,根据保存的所述动态密钥决定是否允许所述终端下一次请求使用API。
优选地,在所述服务器端接收所述终端发送的使用所述API的请求的步骤之前,还包括:所述服务器端接收所述终端发送的请求与安全无关的页面的请求,向所述终端返回所述终端的客户端标识和所述动态密钥。
为了解决上述问题,本申请还公开了一种服务器,包括:第一接收模块,用于在一次终端通过客户端程序请求使用所述服务器的应用程序接口API的过程中,接收所述终端发送的使用所述API的请求,所述请求中包括应用程序接口签名APIKEY,所述APIKEY由所述终端根据所述服务器发送的动态密钥和所述终端保存的公钥生成,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序;校验模块,用于根据所述请求确定所述终端发送的APIKEY与所述服务器的APIKEY一致;生成发送模块,用于允许所述终端使用所述API,并生成新的动态密钥发送给所述终端在下一次请求中使用。
优选地,所述终端发送的所述APIKEY由所述终端根据所述服务器发送的所述动态密钥、所述终端中存储的与所述服务器一致的公钥和/或请求参数,使用加密算法生成。
优选地,所述请求还包括所述终端的客户端标识;所述校验模块包括:获取模块,用于根据所述客户端标识,获得所述服务器存储的所述动态密钥;加密生成模块,用于使用与所述终端相同的所述加密算法,根据获得的所述动态密钥生成所述服务器的APIKEY;判断确定模块,用于判断所述服务器的APIKEY与所述终端发送的所述APIKEY是否一致;若是,则确定所述终端发送的APIKEY与所述服务器的APIKEY一致。
优选地,该服务器还包括:失败模块,用于若所述生成发送模块向所述终端发送所述新的动态密钥失败,则向所述终端发送错误信息,并在所述错误信息中携带所述新的动态密钥;或者,所述服务器端保存生成所述APIKEY的所述动态密钥,根据保存的所述动态密钥决定是否允许所述终端下一次请求使用API。
相应地,本申请还公开了一种终端,包括:第二接收模块,用于接收服务器发送的动态密钥;请求模块,用于在一次通过客户端程序请求使用所述服务器的应用程序接口API的过程中,根据所述动态密钥和所述终端保存的公钥生成应用程序接口签名APIKEY,将所述APIKEY携带在使用所述API的请求中发送给所述服务器,其中,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序;处理模块,用于在获得所述服务器允许后,使用所述服务器的所述API,并接收所述服务器发送的新的动态密钥在下一次请求中使用。
与现有技术相比,本申请具有以下优点:
本申请的技术方案中,服务器端发送给终端(客户端)的一个动态密钥仅在一次使用API的请求中使用,每次请求API使用的APIKEY都不同,由此,实现了请求API的动态APIKEY。通过这种动态的APIKEY,即使APIKEY被非法截取,非法获取者也无法使用APIKEY来使用API,从而解决了现在技术中,终端用户访问和应用API的安全性的问题,有效保证了APIKEY合法用户使用API的安全。
附图说明
图1是根据本申请实施例一的一种数据访问方法的步骤流程图;
图2是根据本申请实施例二的一种数据访问方法的示意图;
图3是根据本申请实施例三的一种数据访问方法的步骤流程图;
图4是根据本申请实施例四的一种服务器的结构框图;
图5是根据本申请实施例五的一种终端的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
实施例一
参照图1,示出了根据本申请实施例一的一种数据访问方法的步骤流程图。
本实施例的数据访问方法包括以下步骤:
步骤S102:在一次终端通过客户端程序请求使用服务器端的API的过程中,服务器端接收终端发送的使用API的请求。
其中,所述请求中包括APIKEY(应用程序接口签名),该APIKEY由终端根据服务器端发送的动态密钥和终端保存的公钥生成。终端保存的公钥通过非通讯方式获取,加密存储,具有较强的保密性,即使中途被非法截取,也很难解密获得。
对服务器端API的访问需通过客户端程序进行,本申请中,客户端程序是指用于请求使用服务器端的API的非浏览器方式的应用程序,如对应于网上银行U盾的应用程序。
步骤S104:服务器端根据所述请求确定终端发送的APIKEY与服务器端的APIKEY一致。
步骤S106:服务器端允许终端使用API,并生成新的动态密钥发送给终端在下一次请求中使用。
服务器端在确定终端发送的APIKEY与服务器端的APIKEY一致后,向终端提供API供终端使用。并且,服务器端会生成新的动态密钥给终端,终端在下一次通过客户端程序请求使用API时,使用该动态密钥和公钥生成新的APIKEY发送给服务器端,以供服务器端下一次校验鉴权使用,实现了每次请求使用不同的APIKEY。
通过本实施例,服务器端发送给终端(客户端)的一个动态密钥仅在一次使用API的请求中使用,每次请求API使用的APIKEY都不同,由此,实现了请求API的动态APIKEY。通过这种动态的APIKEY,即使APIKEY被非法截取,非法获取者也无法使用APIKEY来使用API,从而解决了现在技术中,无法有效保证终端用户,尤其是移动终端用户访问和应用API的安全性的问题,有效保证了APIKEY合法用户使用API的安全。
实施例二
参照图2,示出了根据本申请实施例二的一种数据访问方法的示意图。
本实施例的数据访问方法包括以下步骤:
步骤S202:客户端向服务器端请求使用API。
其中,客户端中保存有与服务器端一致的公用的密钥(公钥)。客户端和服务器端保存的公钥均通过非通讯方法获取,如通过人工输入。客户端通过非浏览器的客户端程序向服务器端请求使用API。
优选地,本实施例中的客户端为移动终端。但不限于此,一般意义上的客户端均可用于实现本实施例,如个人电脑终端等。
步骤S204:客户端根据公钥和动态密钥和/或其它请求参数生成APIKEY,向服务器端请求使用API。
客户端向服务器端进行请求API,应用某种加密算法(somesecret())加密公钥和动态密钥(如果没有就为空)和/或其它请求参数后生成APIKEY进行请求。APIKEY根据公钥和动态密钥和/或其它请求参数生成,因本次尚未获得动态密钥,因此,本次的动态密钥为空,由客户端主要根据公钥和/或其它请求参生成APIKEY。然后,由客户端向服务器端发送本次的APIKEY,APIKEY可以携带在请求中发送,也可以直接发送。加密算法可以由本领域技术人员根据实际情况,任意选用现有的适当算法,本申请对此不作限制。
步骤S206:服务端接收APIKEY,确定客户端发送的APIKEY与服务器端的APIKEY一致。
服务器端接收到客户端发送的APIKEY后,应用同样的加密算法(somesecret())对保存在服务器端的公钥和动态钥(如果没有就为空)和/或其它请求参数进行加密,验证是否正确(即验证客户端发送的APIKEY与服务器端加密保存在服务器端的公钥和动态密钥生成的APIKEY是否一致),如果正确,则产生新的动态密钥并保存,并将新的动态密钥返回给客户端。
步骤S208:服务器端产生新的动态密钥,返回给客户端。
步骤S210:客户端接受新的动态密钥,根据公钥和新的动态密钥和/或其它请求参数生成新的APIKEY,向服务器端进行新的API请求。
本步骤中,客户端接受新的动态密钥并保存,应用某种加密算法(somesecret())加密终端中保存的公钥和新的动态密钥和/或其它请求参数生成新的APIKEY,通过非浏览器的客户端程序向服务器端进行请求。
步骤S212:服务器端接收新的APIKEY,应用同样的加密算法(somesecret())对保存在服务器端的公钥和新的动态密钥和/或其它请求参数进行加密,验证是否正确(即验证客户端发送的APIKEY与服务器端加密公钥和新的动态密钥生成的APIKEY是否一致),如果正确,则再产生一个新的动态密钥,并保存,返回给客户端本次生成的新动态密钥。
这次产生的新动态密钥将在下一次客户端向服务器端发送的APIKEY中使用。
需要说明的是,在通信过程中,可能会有意外发生,如服务器端返回给客户端通信断了,造成客户端与服务器端的动态密钥不一致,使以后的请求都成为非法请求。为解决该问题,可以(1):服务器端向客户端发送错误信息,并在错误信息中携带新的动态密钥;或者,服务器端根据客户端标识,获得服务器端存储的以往的动态密钥并保存,在以后的API请求中,根据以往的动态密钥来决定是否允许客户端下一次使用API;(2)由服务器端提供一个接口,该接口可以让客户端得到动态密钥(安全要求很高,如跟钱有关的);(3)服务器端保存多个历史的动态APIKEY,以便验证用以前的动态密钥来请求是合法的(安全要求低,如论坛什么的)。与其它方式相比,服务器端向客户端发送错误信息,并在错误信息中携带新的动态密钥,或者服务器端根据客户端标识,获得服务器端存储的以住动态密钥的方式安全性更高,能实现安全要求高的API请求验证,且方便快速。
通过本实施例,不仅解决了现在技术的无线通信环境下无法有效保证移动终端用户访问和应用API的安全性的问题,保证了APIKEY合法用户使用API的安全,而且解决了通信意外或故障情况下动态密钥的传递,更为有效地实现了意外情况下APIKEY合法用户使用API的安全。
实施例三
参照图3,示出了根据本申请实施例三的一种数据访问方法的步骤流程图。
本实施例的数据访问方法包括以下步骤:
步骤S302:客户端保存服务器端和客户端一致的密钥(公钥);服务器端保存服务器端和客户端一致的密钥(公钥)。
其中,客户端保存的公钥和服务器端保存的公钥均通过非通讯方法获得。本实施例中,客户端为移动终端。
步骤S304:客户端向服务器端请求跟安全无关的页面,服务器端保存并返回客户端标识(如sessionid)和动态密钥。
本实施例中,客户端通过非浏览器的客户端程序向服务器端进行请求和访问。
通过客户端标识,能够使服务器端根据客户端发送的请求,快速地对客户端的请求进行验证。
步骤S306:客户端保存客户端标识(如sessionid)和动态密钥。
步骤S308:客户端向服务器端进行请求API。
客户端使用某种(somesecret())加密算法,应用动态密钥,公钥和/或其它请求参数生成APIKEY,并将请求地址参数加上APIKEY和客户端标识(如sessionid)对服务器端进行请求。
步骤S310:服务器端接收请求,验证客户端发送的APIKEY与服务器端的APIKEY是否一致,若不一致,执行步骤S312;若一致,执行步骤S314。
本步骤中,服务器端接收客户端的APIKEY、客户端标识(如sessionid)和其它请求参数,根据客户端标识(如sessionid)得到服务器端存储的动态密钥,应用同样的加密算法(somesecret())对保存在服务器端的公钥,动态密钥和/或其它请求参数生成服务器端的APIKEY(server_apikey),验证server_apikey是否跟客户端发送的APIKEY一致。
步骤S312:如果服务器端APIKEY与客户端APIKEY不一致,返回错误信息,不允许客户端使用API,本次请求API流程结束。
步骤S314:如果服务器端APIKEY与客户端APIKEY一致,服务器端产生新的动态密钥,并保存,返回给客户端该新的动态密钥。
步骤S316:客户端接受新的动态密钥,并保存。如果客户端标识(如sessionid)没有失效,返回步骤S308;否则,返回步骤S304。
通过本实施例,实现了请求API的动态APIKEY,使得即使APIKEY被非法截取,非法获取者也无法使用APIKEY来使用API,解决了现有技术中,无法有效保证终端用户访问和应用API的安全性的问题,有效保证了APIKEY合法用户使用API的安全。
实施例四
参照图4,示出了根据本申请实施例四的一种服务器的结构框图。
本实施例的服务器包括:第一接收模块402,用于在一次终端通过客户端程序请求使用服务器的API的过程中,接收终端发送的使用API的请求,所述请求中包括APIKEY,该APIKEY由终端根据服务器发送的动态密钥和终端保存的公钥生成,客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序;校验模块404,用于根据所述请求确定终端发送的APIKEY与服务器的APIKEY一致;生成发送模块406,用于允许终端使用API,并生成新的动态密钥发送给终端在下一次请求中使用。
优选地,终端发送的APIKEY由终端根据服务器发送的动态密钥、终端中存储的与服务器一致的公钥和/或请求参数,使用加密算法生成。
优选地,所述请求还包括终端的客户端标识;校验模块404包括:获取模块,用于根据客户端标识,获得服务器存储的动态密钥;加密生成模块,用于使用与终端相同的加密算法,根据获得的动态密钥生成服务器的APIKEY;判断确定模块,用于判断服务器的APIKEY与终端发送的APIKEY是否一致;若是,则确定终端发送的APIKEY与服务器的APIKEY一致。
优选地,本实施例的服务器还包括:失败模块408,用于若生成发送模块406向终端发送新的动态密钥失败,则向终端发送错误信息,并在错误信息中携带新的动态密钥;或者,保存生成所述APIKEY的动态密钥,根据保存的动态密钥决定是否允许终端下一次请求使用API。
优选地,第一接收模块402,还用于在接收终端发送的使用API的请求之前,接收终端发送的请求与安全无关的页面的请求,向终端返回终端的客户端标识和所述动态密钥。
优选地,本实施例的终端为移动终端。
本实施例的服务器用于实现前述方法实施例中服务器端的数据访问方法,并具有相应的有益效果,在此不再赘述。
实施例五
参照图5,示出了根据本申请实施例五的一种终端的结构框图。
本实施例的终端包括:第二接收模块502,用于接收服务器发送的动态密钥;请求模块504,用于在一次通过客户端程序请求使用服务器的API的过程中,根据动态密钥和终端保存的公钥生成APIKEY,将APIKEY携带在使用API的请求中发送给服务器,其中,客户端程序包括除浏览器之外的用于请求服务器端的API的应用程序;处理模块506,用于在获得服务器允许后,使用服务器的所述API,并接收服务器发送的新的动态密钥在下一次请求中使用。
优选地,请求模块504,用于在一次请求使用服务器的API的过程中,根据服务器发送的动态密钥、存储的与服务器一致的公钥和/或请求参数,使用加密算法,生成APIKEY,将APIKEY携带在使用API的请求中发送给服务器。
优选地,所述请求还包括终端的客户端标识。
优选地,本实施例的终端还包括:初始模块,用于在第二接收模块502接收服务器发送的动态密钥之前,向服务器发送与安全无关的页面的请求,接收服务器返回的客户端标识和所述动态密钥。
优选地,本实施例的终端为移动终端。
本实施例的终端用于实现前述方法实施例中客户端的数据访问方法,并具有相应的有益效果,在此不再赘述。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上对本申请所提供的一种数据访问方法、服务器和终端,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (10)
1.一种数据访问方法,其特征在于,包括:
在一次终端通过客户端程序请求使用服务器端的应用程序接口API的过程中,所述服务器端接收所述终端发送的使用所述API的请求,所述请求中包括应用程序接口签名APIKEY,所述APIKEY由所述终端根据所述服务器端发送的动态密钥和所述终端保存的公钥生成,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序,一个动态密钥仅在一次使用API的请求中使用;
所述服务器端根据所述请求确定所述终端发送的APIKEY与所述服务器端的APIKEY一致;
所述服务器端允许所述终端使用所述API,并生成新的动态密钥发送给所述终端在下一次请求中使用。
2.根据权利要求1所述的方法,其特征在于,所述APIKEY由所述终端根据所述服务器端发送的动态密钥和所述终端保存的公钥生成包括:
所述终端根据所述服务器端发送的所述动态密钥、存储的与所述服务器端一致的公钥和/或请求参数,使用加密算法,生成所述APIKEY。
3.根据权利要求2所述的方法,其特征在于,所述请求还包括所述终端的客户端标识;
所述服务器端根据所述请求确定所述终端发送的APIKEY与所述服务器端的APIKEY一致的步骤包括:所述服务器端根据所述客户端标识,获得所述服务器端存储的所述动态密钥;使用与所述终端相同的所述加密算法,根据获得的所述动态密钥生成所述服务器端的APIKEY;判断所述服务器端的APIKEY与所述终端发送的所述APIKEY是否一致;若是,则确定所述终端发送的APIKEY与所述服务器端的APIKEY一致。
4.根据权利要求1所述的方法,其特征在于,在所述服务器端生成新的动态密钥发送给所述终端在下一次请求中使用的步骤之后,还包括:
若所述服务器端向所述终端发送所述新的动态密钥失败,则所述服务器端向所述终端发送错误信息,并在所述错误信息中携带所述新的动态密钥;
或者,若所述服务器端向所述终端发送所述新的动态密钥失败,所述服务器端保存生成所述APIKEY的所述动态密钥,根据保存的所述动态密钥决定是否允许所述终端下一次请求使用API。
5.根据权利要求1所述的方法,其特征在于,在所述服务器端接收所述终端发送的使用所述API的请求的步骤之前,还包括:
所述服务器端接收所述终端发送的请求与安全无关的页面的请求,向所述终端返回所述终端的客户端标识和所述动态密钥。
6.一种服务器,其特征在于,包括:
第一接收模块,用于在一次终端通过客户端程序请求使用所述服务器的应用程序接口API的过程中,接收所述终端发送的使用所述API的请求,所述请求中包括应用程序接口签名APIKEY,所述APIKEY由所述终端根据所述服务器发送的动态密钥和所述终端保存的公钥生成,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序;
校验模块,用于根据所述请求确定所述终端发送的APIKEY与所述服务器的APIKEY一致;
生成发送模块,用于允许所述终端使用所述API,并生成新的动态密钥发送给所述终端在下一次请求中使用。
7.根据权利要求6所述的服务器,其特征在于,所述终端发送的所述APIKEY由所述终端根据所述服务器发送的所述动态密钥、所述终端中存储的与所述服务器一致的公钥和/或请求参数,使用加密算法生成。
8.根据权利要求7所述的服务器,其特征在于,所述请求还包括所述终端的客户端标识;
所述校验模块包括:获取模块,用于根据所述客户端标识,获得所述服务器存储的所述动态密钥;加密生成模块,用于使用与所述终端相同的所述加密算法,根据获得的所述动态密钥生成所述服务器的APIKEY;判断确定模块,用于判断所述服务器的APIKEY与所述终端发送的所述APIKEY是否一致;若是,则确定所述终端发送的APIKEY与所述服务器的APIKEY一致。
9.根据权利要求6所述的服务器,其特征在于,还包括:
失败模块,用于若所述生成发送模块向所述终端发送所述新的动态密钥失败,则向所述终端发送错误信息,并在所述错误信息中携带所述新的动态密钥;或者,所述服务器端保存生成所述APIKEY的所述动态密钥,根据保存的所述动态密钥决定是否允许所述终端下一次请求使用API。
10.一种终端,其特征在于,包括:
第二接收模块,用于接收服务器发送的动态密钥;
请求模块,用于在一次通过客户端程序请求使用所述服务器的应用程序接口API的过程中,根据所述动态密钥和所述终端保存的公钥生成应用程序接口签名APIKEY,将所述APIKEY携带在使用所述API的请求中发送给所述服务器,其中,所述客户端程序包括除浏览器之外的用于请求所述服务器端的API的应用程序,一个动态密钥仅在一次使用API的请求中使用;
处理模块,用于在获得所述服务器允许后,使用所述服务器的所述API,并接收所述服务器发送的新的动态密钥在下一次请求中使用。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110388487.1A CN103139163B (zh) | 2011-11-29 | 2011-11-29 | 数据访问方法、服务器和终端 |
HK13108863.2A HK1181584A1 (zh) | 2011-11-29 | 2013-07-30 | 數據訪問方法、服務器和終端 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110388487.1A CN103139163B (zh) | 2011-11-29 | 2011-11-29 | 数据访问方法、服务器和终端 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103139163A CN103139163A (zh) | 2013-06-05 |
CN103139163B true CN103139163B (zh) | 2016-01-13 |
Family
ID=48498473
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110388487.1A Active CN103139163B (zh) | 2011-11-29 | 2011-11-29 | 数据访问方法、服务器和终端 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN103139163B (zh) |
HK (1) | HK1181584A1 (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104980445B (zh) * | 2015-07-02 | 2019-04-30 | 郑州悉知信息科技股份有限公司 | 一种通信验证方法、装置及系统 |
CN105025041B (zh) * | 2015-08-25 | 2019-03-12 | 北京百度网讯科技有限公司 | 文件上传的方法、装置和系统 |
CN105187449B (zh) * | 2015-09-30 | 2018-10-02 | 北京恒华伟业科技股份有限公司 | 一种接口调用方法及装置 |
CN105743643A (zh) * | 2016-04-26 | 2016-07-06 | 百度在线网络技术(北京)有限公司 | 通信安全的检测方法及装置 |
CN106850699B (zh) * | 2017-04-10 | 2019-11-29 | 中国工商银行股份有限公司 | 一种移动终端登录认证方法及系统 |
CN108737485B (zh) * | 2017-04-25 | 2021-05-11 | 中移物联网有限公司 | 针对物联网资源的操作的方法及系统 |
CN113645033B (zh) * | 2021-10-15 | 2022-03-22 | 天聚地合(苏州)数据股份有限公司 | 接口密钥重置方法、装置、存储介质及服务器 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101393628A (zh) * | 2008-11-12 | 2009-03-25 | 北京飞天诚信科技有限公司 | 一种新型的网上安全交易系统和方法 |
CN101778381A (zh) * | 2009-12-31 | 2010-07-14 | 卓望数码技术(深圳)有限公司 | 数字证书生成方法、用户密钥获取方法、移动终端及设备 |
CN102184354A (zh) * | 2011-04-02 | 2011-09-14 | 方园 | 一种网上支付防止数据被伪造和劫持的方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8688834B2 (en) * | 2004-07-09 | 2014-04-01 | Toshiba America Research, Inc. | Dynamic host configuration and network access authentication |
-
2011
- 2011-11-29 CN CN201110388487.1A patent/CN103139163B/zh active Active
-
2013
- 2013-07-30 HK HK13108863.2A patent/HK1181584A1/zh unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101393628A (zh) * | 2008-11-12 | 2009-03-25 | 北京飞天诚信科技有限公司 | 一种新型的网上安全交易系统和方法 |
CN101778381A (zh) * | 2009-12-31 | 2010-07-14 | 卓望数码技术(深圳)有限公司 | 数字证书生成方法、用户密钥获取方法、移动终端及设备 |
CN102184354A (zh) * | 2011-04-02 | 2011-09-14 | 方园 | 一种网上支付防止数据被伪造和劫持的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103139163A (zh) | 2013-06-05 |
HK1181584A1 (zh) | 2013-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103139163B (zh) | 数据访问方法、服务器和终端 | |
CN107295011B (zh) | 网页的安全认证方法及装置 | |
CN102299930B (zh) | 一种保障客户端软件安全的方法 | |
CN110473318B (zh) | 解锁方法、实现解锁的设备及计算机可读介质 | |
CN100512201C (zh) | 用于处理分组业务的接入-请求消息的方法 | |
CN106713327A (zh) | 一种验证码安全加固的认证方法及系统 | |
CN107612889B (zh) | 防止用户信息泄露的方法 | |
CN106060078B (zh) | 应用于云平台的用户信息加密方法、注册方法及验证方法 | |
CN108322416B (zh) | 一种安全认证实现方法、装置及系统 | |
CN112989426B (zh) | 授权认证方法及装置、资源访问令牌的获取方法 | |
CN102946392A (zh) | 一种url数据加密传输方法及系统 | |
CN103888938A (zh) | 一种基于参数的动态生成密钥的pki私钥保护方法 | |
CN113067823B (zh) | 邮件用户身份认证和密钥分发方法、系统、设备及介质 | |
CN110166453A (zh) | 一种基于se芯片的接口认证方法、系统及存储介质 | |
CN105491058A (zh) | 一种api访问分布式授权方法及其系统 | |
CN103974248A (zh) | 在能力开放系统中的终端安全性保护方法、装置及系统 | |
CN112672342B (zh) | 数据传输方法、装置、设备、系统和存储介质 | |
CN109218334B (zh) | 数据处理方法、装置、接入控制设备、认证服务器及系统 | |
CN106355106A (zh) | 一种账户信息存储方法及系统 | |
CN115967941A (zh) | 电力5g终端认证方法及认证系统 | |
CN115276978A (zh) | 一种数据处理方法以及相关装置 | |
Khan et al. | Offline OTP based solution for secure internet banking access | |
KR101358375B1 (ko) | 스미싱 방지를 위한 문자메시지 보안 시스템 및 방법 | |
CN109587683B (zh) | 短信防监听的方法及系统、应用程序和终端信息数据库 | |
US20240106633A1 (en) | Account opening methods, systems, and apparatuses |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1181584 Country of ref document: HK |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: GR Ref document number: 1181584 Country of ref document: HK |