Methods, devices, electronic devices and media for resource access and data processing

Abstract

The present disclosure relates to a method, apparatus, electronic device, and medium for resource access and data processing. The method for resource access includes: receiving an operation instruction from a user during the development or use of an application; determining the address information and call information of a target service resource required to execute the operation instruction, where the call information includes: a call timing and a target instruction that the target service resource needs to execute; at the call timing, generating token information related to the call timing according to resource access information and an encryption algorithm pre-obtained from a server; where the resource access information is associated with the access permission of the user account of the user to the service resource; sending an access request carrying the user account, the token information, the address information, and the target instruction to the server; and receiving an access response result from the server; where the access response result is obtained by the server after decrypting and verifying the permission of the token information.

Description

Technical Field

[0001] The present disclosure relates to the technical fields of the Internet and cloud services, and in particular, to a method, apparatus, electronic device, and medium for resource access and data processing. Background Art

[0002] With the development of Internet technology, various complex application systems need to be developed and updated. In order to improve software development efficiency and reduce the workload of software developers, the architectures of some open platforms have emerged. The server encapsulates the services corresponding to computing, storage, or a certain function into a series of application program interfaces (APIs, Application Programming Interfaces) that can be recognized by a computer. These open application program interfaces are usually referred to as open APIs. These open APIs are displayed on the open platform, and developers can access and use relevant service resources through these open APIs without accessing the source code in the server or understanding the details of the internal working mechanism.

[0003] In order to ensure access security, the server currently mostly adopts a method of access verification using a token with an expiration date. This method has the following problems: (1) The token has a certain timeliness. The shorter the validity period, the stronger the security, but the more frequent the token update, the greater the pressure on the server, and the front-end open platform needs to develop the logic processing for replacing the token, increasing the development workload; (2) The system framework for building API access currently usually supports the GET request form in the hypertext transfer protocol (http), and the transmitted parameters are exposed and easily obtained illegally. After the token is obtained illegally, an illegal user can simulate a request, which will pose a risk to the resources and operation of the server. Summary of the Invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, embodiments of the present disclosure provide a method, apparatus, electronic device, and medium for resource access and data processing.

[0005] In a first aspect, embodiments of the present disclosure provide a method for resource access. The method for resource access includes: receiving an operation instruction from a user during the development or use of an application; determining the address information and call information of a target service resource required to execute the operation instruction, where the call information includes: a call timing, and a target instruction that the target service resource needs to execute; at the call timing, generating token information related to the call timing according to resource access information and an encryption algorithm pre-obtained from a server; where the resource access information is associated with the access permission of the user account of the user to the service resource; sending an access request carrying the user account, the token information, the address information, and the target instruction to the server; and receiving an access response result from the server; where the access response result is obtained by the server after decrypting and verifying the permission of the token information.

[0006] According to an embodiment of the present disclosure, the resource access information includes: a user login password associated with the user account and an access secret key for accessing the service resource. Wherein, the generating, at the call timing, token information related to the call timing according to the resource access information and the encryption algorithm pre-obtained from the server includes: combining the timestamp information corresponding to the call timing with the user login password to obtain a string; and encrypting and calculating the string with the access secret key as the encryption secret key according to the encryption algorithm to obtain the token information.

[0007] According to an embodiment of the present disclosure, the method for resource access further includes: obtaining resource access information and an encryption algorithm. Wherein, the obtaining the resource access information and the encryption algorithm includes: when the authorization condition for accessing a specific service resource is met, sending an obtaining request to the server for obtaining the resource access information and the encryption algorithm corresponding to the specific service resource; and receiving a data packet sent by the server, where the data packet carries the resource access information and the encryption algorithm.

[0008] According to an embodiment of the present disclosure, the data packet is in the form of a ciphertext encrypted by a pre-agreed secret key, and the pre-agreed secret key is a confidential content agreed upon between the information sender and receiver. Wherein, the obtaining the resource access information and the encryption algorithm further includes: decrypting the received data packet in the form of a ciphertext based on the pre-agreed secret key to obtain the resource access information and the encryption algorithm in the form of a plaintext.

[0009] According to an embodiment of the present disclosure, the access request includes a POST (a data transmission method in the http protocol) request method in the Hypertext Transfer Protocol (http), and both the user account and the token information are located in a cookie (a dataset related to the user identity tracked and stored on a browser).

[0010] Second aspect, embodiments of the present disclosure provide a method for data processing. The above-mentioned method for data processing includes: receiving an access request sent by a demand side, where the information carried in the above-mentioned access request includes: a user account, token information related to a call timing, address information of a target service resource requested to be called, and a target instruction that the above-mentioned target service resource needs to execute; decrypting and performing permission verification on the above-mentioned token information to obtain an access response result; and sending the above-mentioned access response result to the demand side. Wherein, the above-mentioned token information is generated by the demand side according to resource access information and an encryption algorithm pre-obtained from a service side when calling the above-mentioned target service resource; and the above-mentioned resource access information is associated with the access permission of the above-mentioned user account to the service resource.

[0011] According to an embodiment of the present disclosure, the above-mentioned decrypting and performing permission verification on the above-mentioned token information to obtain an access response result includes: decrypting the above-mentioned token information to obtain decrypted resource access information; performing identity verification on the user corresponding to the above-mentioned user account according to the above-mentioned decrypted resource access information; when the identity verification of the above-mentioned user account passes, determining whether the above-mentioned user account has the permission to call the above-mentioned target service resource according to the association relationship between the user account and the access permission of the service resource pre-configured; when it is determined that the above-mentioned user account has the permission to call the above-mentioned target service resource, sending the above-mentioned target instruction to the target service resource for data processing according to the above-mentioned address information to obtain a data processing result, and using the above-mentioned data processing result as the access response result.

[0012] According to an embodiment of the present disclosure, the above-mentioned decrypting and performing permission verification on the above-mentioned token information to obtain an access response result further includes: when the identity verification of the above-mentioned user account fails, or when it is determined that the above-mentioned user account does not have the permission to call the above-mentioned target service resource, obtaining an access response result indicating access failure.

[0013] According to an embodiment of the present disclosure, the above-mentioned decrypting the above-mentioned token information to obtain decrypted resource access information includes: querying pre-configured target resource access information from a database according to the above-mentioned user account, where the above-mentioned target resource access information includes: a target access secret key for the above-mentioned user account to access an authorized service resource; using the queried above-mentioned target access secret key as a decryption secret key according to a decryption algorithm matching the above-mentioned encryption algorithm, performing decryption calculation on the above-mentioned token information to obtain string information; and splitting the above-mentioned string information to obtain decrypted timestamp information and a user login password.

[0014] According to an embodiment of the present disclosure, the above-mentioned target resource access information further includes: the target user login password associated with the above-mentioned user account. Among them, the above-mentioned identity verification of the user corresponding to the above-mentioned user account according to the decrypted resource access information includes: verifying whether the decrypted timestamp information is consistent with the timestamp information corresponding to the above-mentioned access request; verifying whether the decrypted user login password is consistent with the above-mentioned target user login password; when it is verified that the decrypted timestamp information is consistent with the timestamp information corresponding to the above-mentioned access request, and the decrypted user login password is consistent with the above-mentioned target user login password, it is determined that the identity verification of the user account corresponding to the above-mentioned user account passes; when it is verified that the decrypted timestamp information is inconsistent with the timestamp information corresponding to the above-mentioned access request, and / or the decrypted user login password is inconsistent with the above-mentioned target user login password, it is determined that the identity verification of the user account corresponding to the above-mentioned user account fails.

[0015] In a third aspect, an embodiment of the present disclosure provides a resource access device. The above-mentioned resource access device includes: an instruction receiving module, a resource call determination module, a token generation module, a data sending module, and a data receiving module. The above-mentioned instruction receiving module is used to receive operation instructions of a user during the development or use of an application. The above-mentioned resource call determination module is used to determine the address information and call information of the target service resource that needs to be called to execute the above-mentioned operation instructions, and the above-mentioned call information includes: the call timing, and the target instruction that the above-mentioned target service resource needs to execute. The above-mentioned token generation module is used to generate token information related to the above-mentioned call timing according to the resource access information and encryption algorithm pre-obtained from the server at the above-mentioned call timing. Among them, the above-mentioned resource access information is associated with the access permission of the user's user account to the service resource. The above-mentioned data sending module is used to send an access request carrying the above-mentioned user account, the above-mentioned token information, the above-mentioned address information, and the above-mentioned target instruction to the server. The above-mentioned data receiving module is used to receive an access response result from the server; where the above-mentioned access response result is obtained after the server decrypts and verifies the permission of the above-mentioned token information.

[0016] Fourthly, an embodiment of the present disclosure provides a data processing device. The data processing device includes: a request receiving module, a data processing module, and a result sending module. The request receiving module is configured to receive an access request sent by a demand side. Information carried in the access request includes: a user account, token information related to a call timing, address information of a target service resource to be called, and a target instruction that the target service resource needs to execute. Among them, the token information is generated by the demand side according to resource access information and an encryption algorithm pre-obtained from a server side when calling the target service resource; the resource access information is associated with the access permission of the user account to the service resource. The data processing module is configured to decrypt and verify the permission of the token information to obtain an access response result. The result sending module is configured to send the access response result to the demand side.

[0017] Fifthly, an embodiment of the present disclosure provides an electronic device. The electronic device includes a processor, a communication interface, a memory, and a communication bus. Among them, the processor, the communication interface, and the memory complete communication with each other through the communication bus; the memory is used for storing a computer program; the processor is configured to implement the resource access method or the data processing method as described above when executing the program stored on the memory.

[0018] Sixthly, an embodiment of the present disclosure provides a computer-readable storage medium. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the resource access method or the data processing method as described above is implemented.

[0019] The above technical solutions provided by the embodiments of the present disclosure have at least some or all of the following advantages:

[0020] The overall logic of resource access is that at the calling time, token information is generated through real-time encryption calculation based on the resource access information and encryption algorithm pre-obtained from the server. Moreover, the token information is related to the calling time and the user account's access rights to service resources, such that the token information generated for requests at different times and requests from different users is different, effectively implementing permission verification. On the one hand, since the token information corresponding to each access request is recalculated and there is no need to consider its timeliness, the demand side does not need to exert effort in developing regular token updates or replacements, and the server also does not need to face the pressure caused by frequent token updates. On the other hand, since the generated token information is in encrypted form and related to the calling time, its usage time is only within a very short time period corresponding to one access request and access response. Therefore, even if an access request is intercepted by lawbreakers, the carried token information is very difficult to crack in a short time. Even if the token information can be cracked, it will take a long time, and at this time, the access-response cycle corresponding to this access request has ended and the token information has become invalid, effectively ensuring the security of the server. In addition, it can also effectively improve the fine-grainedness of permission control and achieve refined permission control over the service resources of the same system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present disclosure and used together with the specification to explain the principles of the present disclosure.

[0022] To more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or related technologies. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0023] Figure 1 Schematically shows the system architectures of the methods and apparatuses for resource access and the methods and apparatuses for data processing applicable to the embodiments of the present disclosure;

[0024] Figure 2 Schematically shows the flowchart of the method for resource access according to an embodiment of the present disclosure;

[0025] Figure 3 Schematically shows the detailed implementation flowchart of operation S203 according to the embodiment of the present disclosure;

[0026] Figure 4 Schematically shows the flowchart of the method for resource access according to another embodiment of the present disclosure;

[0027] Figure 5A Schematically shows a detailed implementation flowchart of operation S401 according to the embodiment of the present disclosure;

[0028] Figure 5B Schematically shows another detailed implementation flowchart of operation S401 according to an embodiment of the present disclosure;

[0029] Figure 6 Schematically shows a flowchart of a method for data processing according to an embodiment of the present disclosure;

[0030] Figure 7 Schematically shows a detailed implementation flowchart of operation S602 according to an embodiment of the present disclosure;

[0031] Figure 8 Schematically shows a structural block diagram of a device for resource access according to an embodiment of the present disclosure;

[0032] Figure 9 Schematically shows a structural block diagram of a device for data processing according to an embodiment of the present disclosure; and

[0033] Figure 10 Schematically shows a structural block diagram of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0034] Through analysis, it is found that: in the current API permission verification method, a method of using a token with an expiration date for access verification is adopted. Specifically, when a third-party application requests to access a protected resource (the service resource corresponding to the API), after the server approves the user authorization of the third-party application, it will issue an access token (AccessToken) to the third-party application. This access token contains key attributes such as the authorized access scope and authorized validity period of the third-party application. The third-party application needs to hold this token during the subsequent resource access process until the user actively ends this authorization or the token automatically expires. The expired token can be used to replace a new token that is within the validity period for continued use. In this way, frequent token updates cause a great deal of pressure on the server, and the front-end open platform needs to develop the logic processing for replacing tokens, increasing the development volume.

[0035] In addition, the currently commonly used architecture only achieves access restrictions on the user himself, and does not achieve fine-grained access restrictions on the lower-level resources. For example, for some requirements, it is necessary to restrict access to a specific resource. For example, a certain user P can access resource A, but cannot access resource B, and resources A and B belong to the resources within the same system; for such requirements, the current system framework can only restrict P to either access both A and B at the same time or not access A and B, and cannot achieve a finer degree of access control for resources within the same system.

[0036] In addition, the system framework for constructing API access currently usually only supports the GET request form in the Hypertext Transfer Protocol (http), and the transmitted parameters are exposed and easily obtained illegally. After the token is obtained illegally, an illegal user can simulate a request, which will pose risks to the resources and operation of the server.

[0037] In view of this, embodiments of the present disclosure provide a method, device, electronic device and medium for resource access and data processing, which can generate token information through real-time encryption calculation based on pre-acquired resource access information and encryption algorithms, and the token information is related to the call timing and the access permission of the user account to the service resource, so that the token information generated corresponding to requests at different times and requests of different users is different, effectively realizing permission verification, having the advantages of high security and high authentication efficiency, and being able to control the timeliness of the token in real time. The permission control granularity can reach the specific access permission of a specific service resource (the service resource corresponding to an API), and after the permission modification on the server side takes effect, the token information on the demand side takes effect immediately, without delay or waiting, having more efficient permission management and improving the operation efficiency of the open platform.

[0038] The above method for resource access includes: receiving an operation instruction of a user during the development or use of an application; determining the address information and call information of the target service resource to be called for executing the above operation instruction, where the above call information includes: call timing, and the target instruction that the above target service resource needs to execute; at the above call timing, generating token information related to the above call timing according to the resource access information and encryption algorithm pre-acquired from the server; where the above resource access information is associated with the access permission of the above user account to the service resource; sending an access request carrying the above user account, the above token information, the above address information and the above target instruction to the server; and receiving an access response result from the server; where the above access response result is obtained after the server decrypts and verifies the above token information.

[0039] The above method for data processing includes: receiving an access request sent by the demand side, where the information carried in the above access request includes: user account, token information related to the call timing, address information of the target service resource requested to be called, and the target instruction that the above target service resource needs to execute; decrypting and verifying the above token information to obtain an access response result; and sending the above access response result to the demand side. Wherein, the above token information is generated by the demand side according to the resource access information and encryption algorithm pre-acquired from the server when calling the above target service resource; where the above resource access information is associated with the access permission of the above user account to the service resource.

[0040] To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are only a part rather than all of the embodiments of the present disclosure. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts shall fall within the scope of protection of the present disclosure.

[0041] Figure 1 Schematically shows a system architecture applicable to the methods and apparatuses for resource access and the methods and apparatuses for data processing in the embodiments of the present disclosure.

[0042] Referring Figure 1 As shown, the system architecture 100 applicable to the methods and apparatuses for resource access and the methods and apparatuses for data processing in the embodiments of the present disclosure includes: a demand side and a service side 130, and data interaction is performed between the demand side and the service side 130 through a network. In Figure 1 two types of demand sides are taken as examples, for example, the demand side can be the first demand side 110 represented by a terminal device, or it can also be the second demand side 120 represented by an application server.

[0043] The network is a medium that provides a communication link between the demand side and the service side 130, and can include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0044] The first demand side 110 can be terminal devices 111, 112, 113 that are installed with applications or browsers and have the need to call service resources from the service side 130. The above terminal devices 111, 112, 113 are such as laptop computers, smart phones, tablet computers, smart watches, smart bracelets, smart robots, etc. The above applications include but are not limited to: software development applications, financial applications, shopping applications, image recognition applications, web browser applications, search applications, short video applications, instant messaging tools, email clients, social platform software, etc.

[0045] The second demand side 120 can be an application server that provides application service support for the above terminal devices 111, 112, 113 and has the need to call service resources from the service side 130. The above application server can be a service cluster composed of multiple servers, or a single server, and Figure 1 application servers 121 and 122 are taken as examples. In some scenarios, when the above application servers 121, 122 provide service support for the terminal devices 111, 112, 113, they need to call service resources from the service side 130.

[0046] The server 130 can be a unified management layer for API service resource access and permission verification. In some embodiments, the server 130 itself has API service resources; in other embodiments, the server 130 is spatially independent of the service cluster where the service resources are located, and the server 130 can interact with the service cluster where the service resources are located through a network, so as to realize the invocation of API service resources.

[0047] The server 130 itself can carry a database; or the server 130 can communicate with an external database and have operation permissions on the data in the external database.

[0048] Exemplarily, the server 130 can be a cloud server or a conventional server, or the server can also be an electronic device (functioning similarly to a server) with computing power and API service resource management permissions connected to the network.

[0049] The first user 101 can use a terminal device (corresponding to the first demand side 110) to develop an application, or the second user 102 can use a terminal device to download and use the published application.

[0050] In an exemplary scenario, during the process of the first user 101 using a terminal device to develop an application, the first demand side 110 corresponding to the terminal device executes the resource access method provided by the embodiments of the present disclosure. Correspondingly, the server 130 executes the data processing method provided by the embodiments of the present disclosure.

[0051] For example, in the system architecture composed of the first demand side 110 and the server 130, as shown by the single dotted line in Figure 1 When the applications (such as software development apps, and the first user 101 develops online shopping apps through the software development app) or browsers (such as web-based software development systems, and the first user 101 develops online shopping apps through the web-based software development system) on the terminal devices 111, 112, and 113 are running, they initiate an access request to call the target service resource to the server 130 by executing the resource access method provided by the embodiments of the present disclosure, and receive the access response result from the server 130. The server 130 analyzes and processes the received access request by executing the data processing method provided by the embodiments of the present disclosure, and feeds back the access response result (such as data obtained according to the access request, query results, results after calculating by invoking service resources, etc.) to the terminal devices 111, 112, and 113.

[0052] In another exemplary scenario, when the second user 102 uses a terminal device to use a published application, the application server provides service support for the above application. During this period, the application server, as the second demand end 120, needs to call service resources from the server 130. In this scenario, the second demand end 120 corresponding to the application server executes the resource access method provided by the embodiment of the present disclosure, and correspondingly, the server 130 executes the data processing method provided by the embodiment of the present disclosure.

[0053] For example, in the system architecture composed of the second demand end 120 and the service end 130, refer to Figure 1 As shown by the double-dotted line, when the application (e.g., an online shopping app) or browser (e.g., a web-based online shopping platform) on the terminal device is running, and the application server 121 provides service support for the operation of the application or browser, the application server 121 initiates an access request to call the target service resource (the service resource corresponding to the API interface) to the server 130 by executing the resource access method provided in the embodiment of the present disclosure, and receives the access response result from the server 130. The server 130 analyzes and processes the received access request by executing the data processing method provided in the embodiment of the present disclosure, and feeds back the access response result (e.g., data obtained according to the access request, query results, and results of calculation after calling the service resource, etc.) to the application server 121.

[0054] It should be understood that Figure 1 The number of terminal devices and application servers in the embodiment is only for illustration. Any number of terminal devices and application servers may be provided according to implementation requirements.

[0055] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0056] The first exemplary embodiment of the present disclosure provides a method for resource access. The resource access method of this embodiment can be Figure 1 The first demand end 110 or the second demand end 120 in the example is executed.

[0057] Figure 2 The flowchart of a resource access method according to an embodiment of the present disclosure is schematically shown.

[0058] Reference Figure 2 As shown, the resource access method provided by the embodiment of the present disclosure includes the following operations: S201, S202, S203, S204 and S205. Operations S201 to S205 can be performed by the demand side, refer to Figure 1 As shown, the demand side can be Figure 1The first demand side 110 represented by the terminal device in the example can also be the second demand side 120 represented by the application server.

[0059] In operation S201, an operation instruction of a user during the development or use of an application is received.

[0060] The application here can include but is not limited to: application programs (apps) installed on terminal devices, various mini-programs, or web-based applications (performing operations on relevant data based on a browser), etc.

[0061] The above applications include but are not limited to: software development applications, financial applications, shopping applications, image recognition applications, web browser applications, search applications, short video applications, instant messaging tools, email clients, social platform software, and so on.

[0062] In an implementation scenario, referring to Figure 1 as shown by the single-dot dash line in, the first user 101 is, for example, a software developer. The software developer develops an application based on the software development application or web-based software development system installed on the terminal devices 111, 112, and 113. During this process, the software developer will perform one or more operations on the interaction interface corresponding to the software development application or web-based software development system, so as to receive the operation instruction of the first user 101 during the application development process on the terminal device.

[0063] For example, in one embodiment, the above web-based software development system includes: an open platform, which has an API interface. Users can purchase and use specific API interfaces on this open platform (in some open platforms, users can also use the software development toolkits (SDK packages) corresponding to these API interfaces at the same time) to realize the invocation of the corresponding API service resources, and then realize the development and construction of the application. In another embodiment, the above software development application has the right to use the service resources corresponding to specific API interfaces through a pre-purchase method, and can invoke the service resources corresponding to the authorized APIs. The above purchase is only an example of the authorization condition for accessing specific service resources. In other embodiments, some API service resources can be used without purchase, that is, the authorization conditions can be various forms including purchase and non-purchase (for example, the user's points meet the preset conditions, the user's credit value meets the preset conditions, etc.).

[0064] In another implementation scenario, referring to Figure 1As shown by the double-dashed line, the second user 102 is, for example, a user of an application or a browser, which can be an institutional user or an individual user. The user can perform various operations on the operation interface of the application or the display interface of the browser; thus, when the terminal device receives the operation instruction during the user's use of the application, the terminal device will send a data processing request carrying the operation instruction to the application server 121, and thus the above operation instruction (corresponding to operation S201) is received in the application server 121.

[0065] Exemplarily, the operation instructions during the user's development of the application can include, but are not limited to: obtaining the results of software development requirement research, setting instructions for the system framework, setting instructions for the database framework, instructions for writing and verifying program code, instructions for designing test cases, or instructions for calling test cases for software testing, etc.

[0066] Taking the application as an online shopping app and the browser as a web version of the online shopping platform as an example, the operation instructions during the user's use of the application include, but are not limited to: instructions for registering an account, instructions for logging in to an account, instructions for querying specific goods, instructions for pre-sales consultation, instructions for adding specific goods to the shopping cart, instructions for paying for specific goods, instructions for viewing the logistics information of the paid goods, instructions for initiating after-sales returns, etc.

[0067] In operation S202, determine the address information and call information of the target service resources to be called for executing the above operation instruction, where the above call information includes: the call timing, and the target instruction that the above target service resources need to execute.

[0068] After the demand side 110 (terminal device) or the demand side 120 (application server) receives the operation instruction during the user's development or use of the application, it will analyze the above operation instruction to determine which service resources (target service resources) of the third-party server 130 (non-application server) need to be called at what time (corresponding to the call timing) to execute which instructions (target instructions) during the execution of the above operation instruction. The above call timing refers to the time point when the target service resources need to be called.

[0069] Exemplarily, the above target instructions can include, but are not limited to: data viewing instructions, data querying instructions, data filtering instructions, calculation instructions, data modification instructions, data addition instructions, data deletion instructions, etc. The above-listed instructions can also be functionally combined or split. For example, the data viewing instructions, data querying instructions, and data filtering instructions can be functionally combined; the calculation instructions can be split to obtain multiple sub-calculation instructions, etc.

[0070] Taking the target instruction as a data viewing instruction as an example to describe the specific implementation process of operations S201 and S202. When the operation instruction of the user when using a shopping application is to purchase 1 item of a specific color and specific size, after the demand side 120 (application server) receives the above operation instruction, by analyzing the above operation instruction, it can be determined that at the current moment (calling opportunity), it is necessary to call the inventory service resource (an example of the server side) of the inventory system, and the address information of the target service resource is the access address corresponding to the inventory API interface, to view the inventory quantity, that is, the target instruction is: an inventory viewing instruction for a specific color and specific size of goods (viewing a certain parameter, a certain parameter value).

[0071] The above data viewing instruction can also be: viewing the advertising placement statistics, viewing the traffic audit data, etc. In the implementation scenario corresponding to the data query instruction, data can be queried through some keywords. For example, call the merchant system to query non-self-operated goods on the non-online shopping platform that contain the three keywords "three years old", "boy", and "clothes". In the implementation scenario corresponding to the data screening instruction, for example, call the database service containing test cases to screen the existing test cases that meet the current system framework to obtain the target test cases to be returned. In the implementation scenario corresponding to the calculation instruction, it can be to call the settlement system to perform bill cancellation and bill detail cancellation calculations on the settlement bill. The scenarios of data modification instructions, data addition instructions, and data deletion instructions can be understood by reference, and are not exemplified one by one here.

[0072] In operation S203, at the above calling opportunity, according to the resource access information and encryption algorithm pre-obtained from the server side, generate token information related to the above calling opportunity; wherein the above resource access information is associated with the access permission of the user account of the above user to the service resource.

[0073] The resource access information pre-obtained by the demand side from the server side is associated with the access permission of the user account to the service resource. For example, for API service resources 1 and 2 in the same system, the user account C of user A A has access permission to API service resource 1 and does not have access permission to API service resource 2; the user account C of user B B has access permission to both API service resource 1 and API service resource 2. In this regard, on the server side, a set of resource access information I A will be allocated to the user account C 1 and in the corresponding database on the server side, the above resource access information I 1 will be associated with the user account C AAssociate the access rights to API service resources, and the recording method of the associated relationship is, for example: Resource Access Information I 1 →C A Has access rights to API service resource 1 (service resources not written indicate no access rights); or it can also be: Resource Access Information I 1 →C A Has access rights to API service resource 1, C A Does not have access rights to API service resource 2 (the access rights to API service resources that are not available are also correspondingly described); usually, for simplicity, the first example of the associated relationship recording method can be adopted. Similarly, the server will assign user account C B a set of Resource Access Information I 2 and associate the above Resource Access Information I 2 with the access rights of user account C B The recording method of the associated relationship is, for example: Resource Access Information I 2 →C B Has access rights to API service resource 1, C B Has access rights to API service resource 2.

[0074] After allocating the resource access information and associating the resource access information with the access rights, the server will also send the encryption algorithm and the above-allocated resource access information to the user, for example, through email or other communication media, send Resource Access Information I 1 and the encryption algorithm to user A, and send Resource Access Information I 2 and the encryption algorithm to user B.

[0075] The above encryption algorithm can be a functional package for performing encryption calculations. The encryption algorithms transmitted to all users can be the same, or they can be based on the differences in the security levels of the users' historical accesses. For users with relatively poor security levels, the encryption algorithm transmitted is a functional package with a high level of complexity. For users with relatively good security levels, the encryption algorithm transmitted is a functional package with a medium or low level of complexity. The above functional packages with different levels of complexity are developed by the server in advance. Among them, the functional package with a low level of simulated complexity is illegally intercepted and decrypted through a decryption tool with good computing performance, and it also takes a long time (some take half an hour, some even take several days or longer) to achieve decryption. The decrypted access token has expired within the current request-response cycle, which can ensure security.

[0076] For the user, there is no need to know the specific logic of the encryption algorithm. Just input the resource access information as input information into the terminal device in accordance with the agreed manner, and let the demand side corresponding to the terminal device or the demand side corresponding to the application server execute the preset encryption calculation logic (corresponding to operation S203), then the encrypted token information related to the call timing can be output. This encryption calculation logic can be any encryption logic that the server can decrypt.

[0077] For example, in an implementation scenario, for the operation instructions of user A during the development or use of an application, it is determined that the target service resource to be called for executing the above operation instructions is the API service resource 2; at the call timing, according to the resource access information I 1 previously obtained from the server and the encryption algorithm, the token information related to the above call timing is generated as Token1, and this Token1 is associated with the user account C A of user A and is associated with the authorized service resource: API service resource 1 and is also associated with the call timing.

[0078] In operation S204, send the access request carrying the above user account, the above token information, the above address information, and the above target instruction to the server.

[0079] For example, in an implementation scenario, after generating the token information Token1, send the user account C A , the token information Token1, the address information of the target service resource to be called: API service resource 2, and the target instruction for executing the API service resource 2 to the server.

[0080] In operation S205, receive the access response result from the server; where the above access response result is obtained after the server decrypts and verifies the permission of the above token information.

[0081] In the above operations S204 - S205, the demand side can obtain the corresponding permission verification result from the server according to the user account and the token information.

[0082] From the perspective of the server side, since the association relationship between the user account and the access permission of the service resource is pre-configured and stored in the server, after receiving the access request, the server decrypts and verifies the permission of the token information to determine whether the user account of the current user has the call / access permission for the target service resource.

[0083] For example, in the implementation scenario of operation S205, after the server decrypts and verifies the permission of the token information Token1, the decrypted resource access information is: I 1, and according to the pre-configured and stored association relationship between the user account and the access permission of the service resource, the resource access information I can be determined 1 The corresponding resource access permission is: C A Has access permission to API service resource 1, C A Does not have access permission to API service resource 2. When performing permission verification, it can be obtained that user A does not have access permission to the target service resource: API service resource 2, so an access response result of access failure will be fed back to the demand side. Correspondingly, on the demand side, the access response result received from the server is: access failure.

[0084] Among them, in the case where the permission verification is passed, the server will send the target instruction executed by calling the target service resource to the corresponding target service resource according to the address information of the target service resource to be executed, so as to obtain the corresponding data processing result, and use this data processing result as the access response result to be fed back to the demand side. In the case where the permission verification fails, the server directly feeds back an access response result of access failure to the demand side, and will not forward the call information to the target service resource that the user has no access permission to, effectively ensuring the security of the access.

[0085] Based on the above operations S201~S205, in the resource access method provided by the embodiments of the present disclosure, the overall logic of resource access is that at the call time, the token information is generated by real-time encryption calculation according to the resource access information and the encryption algorithm pre-obtained from the server, and the token information is related to the call time and the access permission of the user account to the service resource, so that the token information generated corresponding to requests at different times and requests of different users is different, effectively realizing permission verification. The setting of the above logic can not only improve the security and fine granularity of access control at the same time, but also avoid various problems caused by regularly replacing the token.

[0086] Specifically, on the one hand, since the token information corresponding to each access request is calculated in real time by each demand side at the time of the call (each request needs to be recalculated), there is no need to consider its timeliness. Therefore, the demand side does not need to make efforts to develop regular token updates or replacements, and the server does not need to face the pressure of frequent token updates. On the other hand, since the generated token information is in encrypted form and related to the call timing, its usage time is only within the extremely short time period corresponding to an access request and an access response. Therefore, even if the access request is intercepted by criminals, the token information carried is difficult to crack in a short time. Even if the token information can be cracked, it will take a long time (exceeding the token validity period). At this time, the access-response cycle corresponding to the access request has ended and the token information has expired, effectively ensuring the security of the server. In addition, it can also effectively improve the granularity of permission management and realize refined permission management of service resources in the same system.

[0087] There are many framework technologies that provide API implementation on the market, for example, frameworks based on the Python development language, or the widely used Django REST framework (a powerful and flexible toolkit for building WEB APIs). Based on the above main technical framework products, when a user logs in and obtains a token, the request sent is in GET mode. The characteristic of the GET request is that the parameters passed are clearly written in the content of the URL. The information sent by the GET request can be clearly seen, including user names, passwords, and other important and sensitive information, which fails to play a role in containing information security. In the logic of resource calls in the disclosed embodiment, the POST request method is supported.

[0088] According to the embodiment of the present disclosure, the access request includes a POST request method in the hypertext transfer protocol, and the user account and the token information are both located in a cookie (a data set about user identity tracked and stored in the website). By using the POST request method to transmit the token information, it is safer than the GET request method, and no sensitive information will be found in the URL, and the token information will not be exposed to the outside.

[0089] In one implementation scenario, when the demand side is a terminal device, the terminal device initiates an access request in the form of a POST request (asking whether it is ready). After the server receives the access request (if ready), it can obtain the corresponding user account and token information from the cookie of the terminal device.

[0090] In another implementation scenario, when the demand side is an application server, the application server obtains the corresponding user account and token information from the cookie of the terminal device, and sends an access request carrying the above user account and token information to the server side.

[0091] In the conventional technology, the server issues a token with an expiration date to the authenticated user. This token is valid for a period of time. If the current server wants to restrict this user from accessing some APIs, the token cannot take effect immediately. It has to wait until the current token expires before it can take effect. This is not conducive to the server's control over users and cannot achieve immediate results. Compared with the conventional technology, the permission control granularity provided by the embodiments of the present disclosure can reach the specific access permissions of a certain API. Moreover, after the administrator sets or updates the access permissions, the corresponding permission control function takes effect immediately, without delay or waiting, having higher operation efficiency and more advantages.

[0092] Figure 3 Schematically shows a detailed implementation flowchart of operation S203 according to an embodiment of the present disclosure.

[0093] According to an embodiment of the present disclosure, the resource access information pre-obtained from the server side includes: the user login password associated with the above user account and the access secret key for accessing the service resources.

[0094] Exemplarily, the user login password associated with the user account C of user A A is: "d!$x0u824_^644i@F" (16-bit length), and the access secret key associated with the user account C A for accessing the service resources (authorized API service resources, for example, API service resource 1) is: "rVkR76M9" (8-bit length). It can be understood that the lengths of the user login password and the access secret key here are used as examples, and the embodiments of the present disclosure do not limit the lengths of the password and the secret key.

[0095] Refer to Figure 3 As shown, in operation S203, at the above call timing, according to the resource access information pre-obtained from the server side and the encryption algorithm, token information related to the above call timing is generated, including the following operations: S301 and S302.

[0096] In operation S301, the timestamp information corresponding to the above call timing is merged with the above user login password to obtain a string.

[0097] For example, the timestamp information corresponding to the above call time is: "1632721553"; the timestamp information "1632721553" is merged with the user login password "d!$x0u824_^644i@F" to obtain a string such as: "1632721553d!$x0u824_^644i@F". It can be understood that here the timestamp information is in front and the user login password is behind during the merging as an example. In other embodiments, when merging the timestamp information with the user login password, the user login password can also be placed in front and the timestamp information can be placed behind. In both cases, when decrypting at the server side and splitting the string, the order of identifying the decrypted timestamp information and the user login password successively corresponds to the merging order here.

[0098] In operation S302, according to the above encryption algorithm, the above access key is used as the encryption key to perform encryption calculation on the above string to obtain token information.

[0099] The encryption algorithm pre-obtained from the server can be various function packages for performing encryption calculation, such as but not limited to: DES encryption algorithm, AES encryption algorithm, RSA encryption algorithm, etc.

[0100] Taking the DES encryption algorithm as an example here, according to the function package corresponding to the DES encryption algorithm, the access key is input into the DES encryption algorithm as the encryption key, and the string "1632721553d!$x0u824_^644i@F" is input into the function package corresponding to the DES encryption algorithm (this function package supports the input of strings and keys of various lengths and can output the unique token information after encryption). Based on the DES encryption algorithm in this function package, encryption calculation is performed, and a unique token information can be output. The token information is, for example, in the following form:

[0101] "N53bTW6tr2X / k / oVgX0PZT1hJ".

[0102] Figure 4 Schematically shows a flowchart of a method for resource access according to another embodiment of the present disclosure.

[0103] According to an embodiment of the present disclosure, in addition to the above operations S201 to S205, the above method for resource access further includes the following operations: S401, obtaining resource access information and an encryption algorithm; for the sake of simplicity of illustration, only operation S401 and operation S203 are schematically shown in Figure 4 Only operation S401 and operation S203 are schematically shown. The above operation S401 is executed before operation S203.

[0104] According to an embodiment of the present disclosure, obtaining resource access information and an encryption algorithm includes: when the authorization condition for accessing a specific service resource is met, sending a request for obtaining the resource access information and the encryption algorithm corresponding to the specific service resource to the server; and receiving a data packet sent by the server, where the data packet carries the resource access information and the encryption algorithm.

[0105] Taking a user purchasing a specific service resource as an example of the authorization condition for the user to meet the access to the specific service resource. In other embodiments, some API service resources can be used without purchase, that is, the authorization conditions can include various forms such as purchase and non-purchase (for example, the user's points meet the preset conditions, the user's credit value meets the preset conditions, etc.).

[0106] Figure 5A Schematically shows a detailed implementation flowchart of operation S401 according to an embodiment of the present disclosure.

[0107] Refer to Figure 5A As shown, in the above operation S401, obtaining the resource access information and the encryption algorithm includes the following operations: S501, S502, and S503.

[0108] In operation S501, receive a confirmation message of successful payment for a specific service resource, where the specific service resource is a service resource that the user is to enjoy when developing or using an application.

[0109] For example, the operator of an application (an example of a user) can purchase a specific service resource corresponding to an API interface for a certain developing application or a published application through an open platform on a terminal device. Then, during the development or use of the application, the user has the access right to the specific service resource (here is an example of meeting the access authorization condition). When the user makes a payment for the service resource corresponding to a specific API interface, and the payment system feeds back a confirmation message of successful payment to the terminal device or the corresponding application server, correspondingly, when the terminal device or the application server (the demand side) receives the confirmation message of successful payment, the confirmation message will trigger the operation of obtaining the resource access information and the encryption algorithm. Here, the payment can include the general meaning of payment using actual or virtual money, deduction payment with points (enjoyable when the points reach the minimum threshold), deduction payment with credit value (enjoyable when the credit value reaches the minimum threshold), etc.

[0110] According to an embodiment of the present disclosure, the above confirmation information includes: a user account (used to indicate the user identity, which can also be described as a user identifier, such as the login name of an open platform, the user name, the mobile phone number, etc.), payment information, a purchased specific service resource (for example, the purchased service resource for image recognition), and the purchase expiration date of the specific service resource (for example, the purchase period is one year, and from the purchase date, the service resource for image recognition can be used for one year).

[0111] In operation S502, according to the above confirmation information, a request for obtaining the resource access information and the encryption algorithm corresponding to the above specific service resource is sent to the above server.

[0112] In one implementation scenario, the server is on the server side of the API service resource corresponding to the API interface in the open platform (which can be a cloud server or a conventional server, or other electronic devices capable of providing service resource services).

[0113] In operation S503, a data packet sent by the server is received, and the above resource access information and the above encryption algorithm are carried in the data packet.

[0114] On the server side, according to the above confirmation information (user account, payment information, purchased specific service resource, and the purchase expiration date of the specific service resource), access permissions for the corresponding service resources are assigned to the user identifier of the demand side, and the resource access information associated with the above access permissions is configured, and the association relationship between the resource access information and the access permissions for the service resources is stored; and the above resource access information and the pre-developed encryption algorithm are sent to the demand side.

[0115] According to an embodiment of the present disclosure, between the demand side ( Figure 1 Example 110 or 120) and the server side ( Figure 1 Example 130), the resource access information and the encryption algorithm can be transmitted through a pre-agreed medium, for example, transmitted by email, or the demand side can obtain the data packet by accessing a specific access address given by the server side (the access password is shared by both the sender and the receiver).

[0116] Figure 5B Another detailed implementation flowchart of operation S401 according to an embodiment of the present disclosure is schematically shown.

[0117] To further enhance the security during information transmission and prevent information from being stolen or leaked during transmission, the above data packet is in the form of ciphertext encrypted with a pre-agreed secret key, and the pre-agreed secret key is confidential information agreed upon between the information sender and receiver. For example, the data packet sent by the server is an encrypted compressed packet, and the secret keys for encryption and decryption are secret keys that are agreed upon between the requester and the server and kept confidential to the outside world.

[0118] Based on the above embodiment of encrypting the data packet with a pre-agreed secret key, referring to Figure 5B As shown, in addition to the above operations S501 - S503, the above operation S401 further includes the following operation S504: Based on the above pre-agreed secret key, decrypt the received data packet in ciphertext form to obtain the resource access information and encryption algorithm in plaintext form.

[0119] The second exemplary embodiment of the present disclosure provides a data processing method. The data processing method of this embodiment can be executed by Figure 1 the server 130 exemplified in

[0120] Figure 6 Schematically shows a flowchart of the data processing method according to an embodiment of the present disclosure.

[0121] Referring to Figure 6 As shown, the data processing method provided by the embodiment of the present disclosure includes the following operations: S601, S602, and S603. Operations S601 - S603 are executed by the server, and the server performs permission management on the API service resources corresponding to the API interfaces accessed by the requester.

[0122] In operation S601, receive the access request sent by the requester. The information carried in the above access request includes: user account, token information related to the invocation timing, address information of the target service resource requested to be invoked, and the target instruction that the above target service resource needs to execute.

[0123] Among them, the above token information is generated by the above requester when invoking the above target service resource based on the resource access information and encryption algorithm previously obtained from the server; among them, the above resource access information is associated with the access permission of the above user account to the service resource.

[0124] In operation S602, decrypt and perform permission verification on the above token information to obtain the access response result.

[0125] In operation S603, send the above access response result to the requester.

[0126] In one embodiment, after performing the above operations S201 to S203 on the demand side, operation S204 is performed to send an access request carrying the above user account, the above token information, the above address information, and the above target instruction to the server. Correspondingly, on the server side, the access request sent by the demand side is received (corresponding to operation S601). Then, the server performs operation S602 to obtain an access response result, and performs operation S603 to send the above access response result to the demand side. Correspondingly, on the demand side, the access response result sent by the server is received (corresponding to operation S205).

[0127] On the one hand, since the token information corresponding to each access request is calculated in real time by each demand side at the call time (each request needs to be recalculated) and there is no need to consider its timeliness, the demand side does not need to spend effort on the development of regular token updates or replacements, and the server does not need to face the pressure caused by frequent token updates. On the other hand, since the above token information is in encrypted form and related to the call time, its usage time is only within a very short time period corresponding to an access request and an access response. Therefore, even if the access request is intercepted by illegal elements, the carried token information is very difficult to crack in a short time. Even if the token information can be cracked, it takes a long time (longer than the token validity period), and at this time, the access-response cycle corresponding to this access request has ended and the token information has become invalid, effectively ensuring the security of the server. In addition, it can also effectively improve the fine-grainedness of permission control and achieve refined permission control over the service resources of the same system.

[0128] Figure 7 Schematically shows a detailed implementation flowchart of operation S602 according to an embodiment of the present disclosure.

[0129] According to an embodiment of the present disclosure, with reference to Figure 7 as shown, in the above operation S602, decrypting the above token information and performing permission verification to obtain an access response result includes the following operations: S701, S702, S703a, and S704a.

[0130] With reference to Figure 7 as shown, on the basis of the embodiment including the above operations S701, S702, S703a, and S704a, the above operation S602 may further include operations S703b and S704b.

[0131] In operation S701, decrypt the above token information to obtain decrypted resource access information.

[0132] The algorithm used for decryption is a decryption algorithm for the encryption algorithm preset by the server, and the corresponding decryption process can be the reverse process of the encryption process.

[0133] According to an embodiment of the present disclosure, the above token information is decrypted to obtain decrypted resource access information, including the following sub-operations: S7011, S7012, S7013.

[0134] In sub-operation S7011, according to the above user account, the pre-configured target resource access information is queried from the database. The above target resource access information includes: the target access secret key for the above user account to access the authorized service resource.

[0135] For example, the queried user account is C A The target access secret key corresponding to the authorized API service resource 1 is: "rVkR76M9".

[0136] In sub-operation S7012, according to the decryption algorithm matching the above encryption algorithm, the queried above target access secret key is used as the decryption secret key to perform decryption calculation on the above token information to obtain string information.

[0137] The string information obtained by performing the decryption calculation is, for example: "1632721553d!$x0u824_^644i@F".

[0138] In sub-operation S7013, the above string information is split to obtain the decrypted timestamp information and the user login password.

[0139] According to the order that is consistent with the merging during encryption, the string information is split. For example, in the order that the timestamp information is in the front and the user login password is in the back, the decrypted timestamp information is: "1632721553", and the decrypted user login password is: "d!$x0u824_^644i@F".

[0140] In operation S702, according to the above decrypted resource access information, the identity of the user corresponding to the above user account is verified.

[0141] In addition to the target access secret key, the above pre-configured target resource access information further includes: the target user login password associated with the above user account.

[0142] In the above operation S702, according to the decrypted resource access information above, identity verification is performed on the user corresponding to the above user account, including: verifying whether the decrypted timestamp information is consistent with the timestamp information corresponding to the above access request; verifying whether the decrypted user login password is consistent with the above target user login password; when it is verified that the decrypted timestamp information is consistent with the timestamp information corresponding to the above access request, and the decrypted user login password is consistent with the above target user login password, it is determined that the identity verification of the user account corresponding to the above user account passes; when it is verified that the decrypted timestamp information is inconsistent with the timestamp information corresponding to the above access request, and / or the decrypted user login password is inconsistent with the above target user login password, it is determined that the identity verification of the user account corresponding to the above user account fails.

[0143] Based on the above, when performing identity verification on a user, not only it is necessary to verify whether the user login password decrypted from the token information in the current access request matches the user account, but also it is necessary to verify whether the timestamp information carried in the current access request is the timestamp at the time when the access request is initiated. If the timestamp information is inconsistent, it will also cause the verification to fail, thereby preventing the access of forged requests initiated by illegally intercepting token information to service resources and effectively ensuring the security of the server.

[0144] In operation S703a, when the identity verification of the above user account passes, according to the pre-configured association relationship between the user account and the access permission of the service resource, it is determined whether the above user account has the permission to call the above target service resource.

[0145] In operation S704a, when it is determined that the above user account has the permission to call the above target service resource, according to the above address information, the above target instruction is sent to the target service resource for data processing to obtain a data processing result, and the above data processing result is used as an access response result.

[0146] In operation S703b, when the identity verification of the above user account fails, an access response result indicating access failure is obtained.

[0147] In operation S704b, when it is determined that the above user account does not have the permission to call the above target service resource, an access response result indicating access failure is obtained.

[0148] The third exemplary embodiment of the present disclosure provides a resource access device.

[0149] Figure 8 Schematically shows a structural block diagram of a resource access device according to an embodiment of the present disclosure.

[0150] Refer to Figure 8As shown in the figure, the device 800 for resource access provided by an embodiment of the present disclosure includes: an instruction receiving module 801, a resource call determination module 802, a token generation module 803, a data sending module 804, and a data receiving module 805.

[0151] The above-mentioned instruction receiving module 801 is used to receive the operation instructions of the user during the development or use of the application.

[0152] The above-mentioned resource call determination module 802 is used to determine the address information and call information of the target service resource required to execute the above-mentioned operation instructions. The above-mentioned call information includes: the call timing, and the target instructions that the above-mentioned target service resource needs to execute.

[0153] The above-mentioned token generation module 803 is used to generate token information related to the above-mentioned call timing according to the resource access information and encryption algorithm pre-obtained from the server at the above-mentioned call timing. Wherein the above-mentioned resource access information is associated with the access permission of the user account of the above-mentioned user to the service resource.

[0154] The above-mentioned data sending module 804 is used to send an access request carrying the above-mentioned user account, the above-mentioned token information, the above-mentioned address information, and the above-mentioned target instructions to the server.

[0155] The above-mentioned data receiving module 805 is used to receive the access response result from the server; wherein the above-mentioned access response result is obtained after the server decrypts and verifies the above-mentioned token information.

[0156] According to an embodiment of the present disclosure, in addition to including the above-mentioned instruction receiving module 801, resource call determination module 802, token generation module 803, data sending module 804, and data receiving module 805, the above-mentioned device 800 for resource access may further include: an access information and encryption algorithm acquisition module, which is used to acquire resource access information and encryption algorithm.

[0157] The above-mentioned access information and encryption algorithm acquisition module may include functional modules or sub-modules for implementing the above-mentioned operations S501 to S503, or the above-mentioned operations S501 to S504.

[0158] The fourth exemplary embodiment of the present disclosure provides a data processing device.

[0159] Figure 9 Schematically shows a structural block diagram of a data processing device according to an embodiment of the present disclosure.

[0160] Refer to Figure 9 As shown in the figure, the data processing device 900 provided by an embodiment of the present disclosure includes: a request receiving module 901, a data processing module 902, and a result sending module 903.

[0161] The above-mentioned request receiving module 901 is used to receive the access request sent by the demand side. The information carried by the above-mentioned access request includes: user account, token information related to the call timing, address information of the target service resource requested to be called, and the target instruction that the above-mentioned target service resource needs to execute. Among them, the above-mentioned token information is generated by the demand side according to the resource access information and encryption algorithm pre-obtained from the server when calling the above-mentioned target service resource; among them, the above-mentioned resource access information is associated with the access permission of the above-mentioned user account to the service resource.

[0162] The above-mentioned data processing module 902 is used to decrypt and verify the permission of the above-mentioned token information to obtain an access response result.

[0163] The above-mentioned result sending module 903 is used to send the above-mentioned access response result to the demand side.

[0164] In the above-mentioned third embodiment, any multiple of the above-mentioned instruction receiving module 801, resource call determination module 802, token generation module 803, data sending module 804, and data receiving module 805 can be combined and implemented in one module, or any one of them can be split into multiple modules. Or, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. At least one of the instruction receiving module 801, resource call determination module 802, token generation module 803, data sending module 804, and data receiving module 805 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), programmable logic array (PLA), system on chip, system on substrate, system on package, application specific integrated circuit (ASIC), or can be implemented by any other reasonable way of integrating or packaging circuits, etc., in hardware or firmware, or implemented in any one of the three implementation ways of software, hardware, and firmware, or in an appropriate combination of any several of them. Or, at least one of the instruction receiving module 801, resource call determination module 802, token generation module 803, data sending module 804, and data receiving module 805 can be at least partially implemented as a computer program module, and when the computer program module runs, it can execute the corresponding functions.

[0165] In the fourth embodiment described above, any combination of the request receiving module 901, the data processing module 902, and the result sending module 903 can be integrated into one module, or any one of them can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. At least one of the request receiving module 901, the data processing module 902, and the result sending module 903 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on substrate, a system on package, an application specific integrated circuit (ASIC), or any other reasonable way of integrating or packaging circuits, etc., implemented by hardware or firmware, or implemented in any one of the three ways of software, hardware, and firmware, or in an appropriate combination of any of them. Alternatively, at least one of the request receiving module 901, the data processing module 902, and the result sending module 903 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0166] The fifth exemplary embodiment of the present disclosure provides an electronic device.

[0167] Figure 10 A block diagram of the electronic device provided by the embodiment of the present disclosure is schematically shown.

[0168] Referring to Figure 10 As shown, the electronic device 1000 provided by the embodiment of the present disclosure includes a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004. Among them, the processor 1001, the communication interface 1002, and the memory 1003 complete communication with each other through the communication bus 1004; the memory 1003 is used to store a computer program; when the processor 1001 executes the program stored on the memory, it implements the method of resource access or the method of data processing as described above.

[0169] The sixth exemplary embodiment of the present disclosure further provides a computer-readable storage medium. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the method of resource access or the method of data processing as described above.

[0170] The computer-readable storage medium may be included in the device / apparatus described in the above embodiment; or it may exist alone without being assembled into the device / apparatus. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0171] According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: portable computer disks, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the present disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, apparatus, or device.

[0172] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0173] The above are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to these embodiments shown herein, but rather to the broadest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for resource access, characterized in that, applied to the demand side, the method includes: Receiving an operation instruction of a user during the development or use of an application; Determining the address information and call information of the target service resource required to execute the operation instruction, where the call information includes: call timing, and the target instruction that the target service resource needs to execute; the call timing refers to the time point when the target service resource needs to be called; At the call timing, generating token information related to the call timing according to the resource access information and encryption algorithm pre-obtained from the server; where the resource access information is associated with the access permission of the user account of the user to the service resource; Sending an access request carrying the user account, the token information, the address information, and the target instruction to the server; and Receiving an access response result from the server; where the access response result is obtained after the server decrypts and verifies the permission of the token information.

2. The method according to claim 1, characterized in that, The resource access information includes: the user login password associated with the user account and the access secret key for accessing the service resource; Among them, the generating token information related to the call timing according to the resource access information and encryption algorithm pre-obtained from the server at the call timing includes: Combining the timestamp information corresponding to the call timing with the user login password to obtain a string; and According to the encryption algorithm, using the access secret key as the encryption key to perform encryption calculation on the string to obtain the token information.

3. The method according to claim 1 or 2, characterized in that, It further includes: Obtaining resource access information and an encryption algorithm; Among them, the obtaining resource access information and an encryption algorithm includes: When the authorization condition for accessing a specific service resource is met, sending an obtaining request to the server for obtaining the resource access information and encryption algorithm corresponding to the specific service resource; and Receiving a data packet sent by the server, where the data packet carries the resource access information and the encryption algorithm.

4. The method according to claim 3, characterized in that, The data packet is in the form of a ciphertext encrypted by a pre-agreed secret key, and the pre-agreed secret key is a confidential content agreed upon between the information sending and receiving parties; Among them, the obtaining resource access information and an encryption algorithm further includes: Based on the pre-agreed secret key, decrypting the received ciphertext-form data packet to obtain the resource access information and encryption algorithm in plaintext form.

5. The method according to claim 1, characterized in that, The access request includes the POST request method in the Hypertext Transfer Protocol, and both the user account and the token information are located in the cookie.

6. A method for data processing, characterized in that, applied to the server, the method includes: Receive an access request sent by the demand side. The information carried in the access request includes: user account, token information related to the invocation timing, address information of the target service resource to be invoked, and the target instruction that the target service resource needs to execute. Among them, the token information is generated by the demand side according to the resource access information and encryption algorithm pre-obtained from the server when invoking the target service resource. Among them, the resource access information is associated with the access permission of the user account to the service resource. The invocation timing refers to the time point when the target service resource needs to be invoked. Decrypt and verify the permission of the token information to obtain an access response result; and Send the access response result to the demand side.

7. The method according to claim 6, characterized in that The decrypting and permission-verifying the token information to obtain an access response result includes: Decrypt the token information to obtain the decrypted resource access information; According to the decrypted resource access information, perform identity verification on the user corresponding to the user account; In the case where the identity verification of the user account passes, determine whether the user account has the invocation permission for the target service resource according to the pre-configured association relationship between the user account and the access permission of the service resource; In the case where it is determined that the user account has the invocation permission for the target service resource, send the target instruction to the target service resource for data processing according to the address information to obtain a data processing result, and the data processing result is used as the access response result.

8. The method according to claim 7, characterized in that The decrypting and permission-verifying the token information to obtain an access response result further includes: In the case where the identity verification of the user account fails, or in the case where it is determined that the user account does not have the invocation permission for the target service resource, obtain an access response result indicating access failure.

9. The method according to claim 7, characterized in that The decrypting the token information to obtain the decrypted resource access information includes: According to the user account, query the pre-configured target resource access information from the database. The target resource access information includes: the target access secret key used by the user account to access the authorized service resource; Using the queried target access secret key as the decryption secret key, perform decryption calculation on the token information according to the decryption algorithm matching the encryption algorithm to obtain string information; and Split the string information to obtain the decrypted timestamp information and the user login password.

10. The method according to claim 9, characterized in that The target resource access information further includes: the target user login password associated with the user account; Among them, the performing identity verification on the user corresponding to the user account according to the decrypted resource access information includes: Verify whether the decrypted timestamp information is consistent with the timestamp information corresponding to the access request; Verify whether the decrypted user login password is consistent with the target user login password. When it is verified that the decrypted timestamp information is consistent with the timestamp information corresponding to the access request, and the decrypted user login password is consistent with the target user login password, it is determined that the identity verification of the user account corresponding to the user account passes; When it is verified that the decrypted timestamp information is inconsistent with the timestamp information corresponding to the access request, and / or the decrypted user login password is inconsistent with the target user login password, it is determined that the identity verification of the user account corresponding to the user account fails.

11. A resource access device, Characterized in that, The device is a demand side, including: An instruction receiving module, configured to receive an operation instruction of a user during the development or use of an application; A resource call determination module, configured to determine the address information and call information of the target service resource required to execute the operation instruction, where the call information includes: a call timing, a target instruction that the target service resource needs to execute; the call timing refers to the time point when the target service resource needs to be called; A token generation module, configured to generate token information related to the call timing according to the resource access information and encryption algorithm pre-obtained from the server at the call timing; where the resource access information is associated with the access permission of the user account of the user to the service resource; A data sending module, configured to send an access request carrying the user account, the token information, the address information, and the target instruction to the server; and A data receiving module, configured to receive an access response result from the server; where the access response result is obtained after the server decrypts and verifies the permission of the token information.

12. A data processing device, Characterized in that, The device is a server side, including: A request receiving module, configured to receive an access request sent by the demand side, where the information carried by the access request includes: a user account, token information related to the call timing, the address information of the target service resource requested to be called, and the target instruction that the target service resource needs to execute; where the token information is generated by the demand side according to the resource access information and encryption algorithm pre-obtained from the server when calling the target service resource; where the resource access information is associated with the access permission of the user account to the service resource; the call timing refers to the time point when the target service resource needs to be called; A data processing module, configured to decrypt and verify the permission of the token information to obtain an access response result; and A result sending module, configured to send the access response result to the demand side.

13. An electronic device, Characterized in that, It includes a processor, a communication interface, a memory, and a communication bus. Among them, the processor, the communication interface, and the memory complete communication with each other through the communication bus; The memory is used to store a computer program; The processor, when executing the program stored on the memory, implements the method described in any one of claims 1-10.

14. A computer-readable storage medium, on which a computer program is stored, Characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1-10.

Images