CN115361173A - Data processing method and system for database, storage medium and processor - Google Patents

Data processing method and system for database, storage medium and processor Download PDF

Info

Publication number
CN115361173A
CN115361173A CN202210882461.0A CN202210882461A CN115361173A CN 115361173 A CN115361173 A CN 115361173A CN 202210882461 A CN202210882461 A CN 202210882461A CN 115361173 A CN115361173 A CN 115361173A
Authority
CN
China
Prior art keywords
data
interface
database
caller
verification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210882461.0A
Other languages
Chinese (zh)
Inventor
龚敏
吴郡
邓志华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zoomlion Smart Agriculture Co ltd
Original Assignee
Zoomlion Smart Agriculture Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zoomlion Smart Agriculture Co ltd filed Critical Zoomlion Smart Agriculture Co ltd
Priority to CN202210882461.0A priority Critical patent/CN115361173A/en
Publication of CN115361173A publication Critical patent/CN115361173A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The embodiment of the application provides a data processing method, a system, a processor and a storage medium for a database. The data processing method comprises the following steps: acquiring an interface request initiated by an interface caller, wherein the interface request carries verification data; determining the user type of the interface caller according to the user identification in the verification data; verifying the verification data according to a verification mode corresponding to the user type; in the case of verification of the verification data, the interface caller is allowed to access the database. The interface callers of different user types can be distinguished according to the user identification in the verification data. Interface requests initiated by interface callers of different user types are processed according to corresponding verification modes, and interface calling compatible with the interface callers of different user types is realized. And the calling efficiency is effectively improved under the condition of ensuring the calling safety.

Description

Data processing method and system for database, storage medium and processor
Technical Field
The present application relates to the field of computer technologies, and in particular, to a data processing method and system for a database, a storage medium, and a processor.
Background
In the prior art, before an interface caller calls an interface of a service provider, no matter the caller is a front-end caller or a back-end caller, an account and a password provided by the service provider are used for simulated login, and then a login certificate is taken to call the interface of the service provider, so that the logic algorithm of the method is complex and the calling efficiency is low. When the service provider makes the access amount report, the service provider cannot quickly distinguish whether the access is the access of the front-end user (web browser, APP, applet and the like) or the access of the back-end service, and the safety is low.
Disclosure of Invention
An object of the embodiments of the present application is to provide a data processing method, a system, a storage medium, and a processor for a database.
In order to achieve the above object, a first aspect of the present application provides a data processing method for a database, where the database is a database of a service system that provides backend services, and the data processing method includes:
acquiring an interface request initiated by an interface caller, wherein the interface request carries verification data;
determining the user type of the interface caller according to the user identification in the verification data;
verifying the verification data according to a verification mode corresponding to the user type;
in the case of verification of the verification data, the interface caller is allowed to access the database.
In an embodiment of the present application, the verification data includes message header data, and determining the user type of the interface caller according to the user identifier in the verification data includes: determining the user type as a first user type under the condition that the message header data does not comprise the user identification; and determining the user type as a second user type under the condition that the message header data comprises the user identification.
In an embodiment of the application, the verification data further includes login data, and verifying the verification data according to a verification mode corresponding to the user type includes: verifying login data under the condition that the user type is determined to be the first user type; in the event that the validation data is validated, allowing the interface caller to access the database comprises: under the condition that the login data passes the verification, returning a first notice that the login data passes the verification to the interface caller; receiving a data access interface of the interface caller calling the database according to the first notification; and searching login data corresponding to the first notification in a service system providing back-end service, and allowing the interface caller to access the database under the condition that the interface caller is determined to have the calling authority.
In an embodiment of the application, the data processing method further includes: the interface caller is prohibited from accessing the database if any of the following is satisfied: the first notification of the interface caller is null; the login data corresponding to the first notification does not exist; the interface caller has no call authority.
In an embodiment of the present application, verifying the verification data according to the verification method corresponding to the user type includes: under the condition that the user type is determined to be a second user type, signature data included in the verification data are obtained and verified; in the event that the validation data is validated, allowing the interface caller to access the database comprises: if the signature data passes the verification, returning a second notice that the signature data passes the verification to the interface caller; and the receiving interface caller calls a data access interface of the database according to the second notification so as to allow the interface caller to access the database.
In an embodiment of the present application, the verification data further includes user information, and the obtaining and verifying signature data included in the verification data includes: determining key data corresponding to the user identification; acquiring a timestamp included in the verification data, wherein the timestamp is the current time acquired by an interface caller when the interface caller initiates an interface request; generating corresponding standard signature data according to the user identification, the key data, the timestamp and the user information by adopting a signature algorithm the same as that of the interface caller; in the case where the signature data agrees with the standard signature data, it is determined that the verification data is verified.
In an embodiment of the application, the data processing method further includes: the interface caller is prohibited from accessing the database if any of the following is satisfied: the signature data and/or the time stamp are not included in the verification data; key data corresponding to the user identification is not searched in a service system providing the back-end service; the signature data is not consistent with the standard signature data.
In an embodiment of the application, the data processing method further includes: acquiring an access white list, wherein the access white list comprises an allowed interface address allowing access to a database; determining a request address carried by an interface request under the condition that the verification data passes the verification; allowing the interface caller to access the database if the request address is included in the allowed interface address; in the case where the request address is not included in the allowed interface address, the interface caller is prohibited from accessing the database.
A second aspect of the present application provides a processor configured to perform the above-mentioned data processing method for a database.
A third aspect of the present application provides a data processing system comprising: the first terminal is used for initiating an interface request for accessing a database of a service system to the service system providing the back-end service by an interface caller of a first user type; the second terminal is used for initiating an interface request for accessing a database of the service system to the service system providing the back-end service by the interface caller of the second user type; and a processor comprising the above, the processor being configured to perform the above data processing method for a database.
A fourth aspect of the present application provides a machine-readable storage medium having stored thereon instructions which, when executed by a processor, cause the processor to be configured to perform the above-described data processing method for a database.
Through the technical scheme, the interface call initiates an interface request to a service system user providing the back-end service, and the user type of the interface caller is determined according to the user identification in the verification data carried in the interface request. And then, verifying the verification data according to a verification mode corresponding to the user type, and allowing the interface caller to access the database under the condition that the verification data passes verification. The interface callers of different user types can be distinguished according to the user identification in the verification data. Interface requests initiated by interface callers of different user types are processed according to corresponding verification modes, and the interface invocations compatible with the interface callers of different user types are realized. And the calling efficiency is effectively improved under the condition of ensuring the calling safety.
Additional features and advantages of embodiments of the present application will be described in detail in the detailed description which follows.
Drawings
The accompanying drawings, which are included to provide a further understanding of the embodiments of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the detailed description serve to explain the embodiments of the application and not to limit the embodiments of the application. In the drawings:
fig. 1 schematically shows an application environment diagram of a data processing method for a database according to an embodiment of the present application;
FIG. 2 schematically shows a flow diagram of a data processing method for a database according to an embodiment of the present application;
FIG. 3 schematically illustrates a timing diagram of a first user type invocation interface according to an embodiment of the present application;
FIG. 4 schematically illustrates a timing diagram of a second user type invocation interface according to an embodiment of the present application;
FIG. 5 schematically shows a schematic representation of steps of a data processing method for a database according to the present application;
fig. 6 schematically shows a block diagram of a data processing system for a database according to an embodiment of the present application.
Fig. 7 schematically shows a block diagram of a data processing apparatus for a database according to an embodiment of the present application;
fig. 8 schematically shows an internal structure diagram of a computer device according to an embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it should be understood that the specific embodiments described herein are only used for illustrating and explaining the embodiments of the present application and are not used for limiting the embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The data processing method for the database provided by the application can be applied to the application environment shown in fig. 1. Wherein, the processor 103 communicates with the first terminal 101 and the second terminal 102 through the network and the through-network, respectively. The first terminal 101 and the second terminal 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the processor 103 may be implemented by an independent server or a server cluster composed of a plurality of servers. The first terminal 101 is configured to initiate, by an interface caller of a first user type, an interface request for accessing a database of a service system to the service system providing a backend service. The second terminal 102 is configured to initiate, by the interface caller of the second user type, an interface request for accessing a database of the service system to the service system providing the backend service.
Fig. 2 schematically shows a flow chart of a data processing method for a database according to an embodiment of the present application. As shown in fig. 2, in an embodiment of the present application, a data processing method for a database is provided, where the database is a database of a service system providing backend services. The embodiment is mainly illustrated by applying the method to the processor 103 in fig. 1, and includes the following steps:
step 202, an interface request initiated by an interface caller is obtained, and the interface request carries verification data.
And step 204, determining the user type of the interface caller according to the user identification in the verification data.
And step 206, verifying the verification data according to the verification mode corresponding to the user type.
In step 208, the interface caller is allowed to access the database if the verification data passes the verification.
An interface caller is an object that initiates a call to an interface of a service system that provides backend services. The interface caller must call the interface according to the interface protocol specified by the service system to access the database of the service system. For example, it may be the HTTP protocol (hypertext transfer protocol). Interface callers, also known as service consumers, include front-end callers and back-end callers. An interface request refers to a request from an interface caller to initiate a communication setup to a service system. When receiving an interface request initiated by an interface caller, the processor may obtain verification data carried in the interface request. The verification data includes a plurality of kinds, such as an account number of a caller, a password, a request parameter, a time stamp parameter, and signature data. The user identification in the authentication data may distinguish between interface callers of different user types. The user type of the interface caller may be a front-end caller, a back-end caller, other types of callers, and the like. The processor may distinguish the type of interface caller based on the user identification in the authentication data. The verification mode corresponding to the user type can be login verification or signature authentication, and other verification modes which can verify the verification data of the interface caller so as to avoid an illegal caller without call authority from accessing the database. For example, the front-end caller may be log-in verified and the back-end caller may be signature verified. By performing different verifications on interface callers of different user types, the calling efficiency of the processor can be improved. Under the condition that the verification data passes the verification according to the verification mode corresponding to the user type, the processor can allow the interface caller to call the interface so as to access the database of the service system providing the back-end service, and the security of the database can be improved.
In one embodiment, the validation data includes message header data, and determining the user type of the interface caller based on the user identification in the validation data includes: determining the user type as a first user type under the condition that the message header data does not comprise the user identification; and determining the user type as a second user type under the condition that the message header data comprises the user identification.
Message header data, http header, refers to the components of the protocol header portion in hypertext transfer protocol request and response messages. The message header data is used to accurately describe the behavior of the resource, server or client being acquired, defining specific operating parameters in the http transaction. The interface caller can transmit data such as user identification, signature data, time stamp and the like of the interface caller through message header data to verify the interface caller. The user identifier is a field which can be used for distinguishing different user types from different interface callers, and the value of the field can represent the account number of the client, namely the account number of the interface caller. For example, it may be specified that the interface caller must configure the user identifier of cross-session-client-id field in the message header data, and the value clientId of the field represents the client account, i.e. the interface caller account, so as to distinguish different interface callers. The processor determines the user type to be a first user type when determining that the user identification of the cross-session-client-id field is not included in the message header data. The processor determines the user type to be a second user type when determining that the message header data comprises the user identification of the cross-session-client-id field. The first user type is a front-end caller, and the second user type is a back-end caller. It is to be understood that the first and second implementations are relative.
In one embodiment, the verification data further includes login data, and verifying the verification data according to a verification mode corresponding to the user type includes: verifying login data under the condition that the user type is determined to be the first user type; in the event that the validation data is validated, allowing the interface caller to access the database comprises: under the condition that the login data passes the verification, returning a first notice that the login data passes the verification to the interface caller; receiving a data access interface of the interface caller calling the database according to the first notification; and searching login data corresponding to the first notification in a service system providing back-end service, and allowing the interface caller to access the database under the condition that the interface caller is determined to have the calling authority.
The login data is data such as a user name and a password input on a web page at the front end when the interface caller initiates a login request to log in the user. The processor determines the user type of the interface caller as a first user type when determining that the message header data does not include the user identifier. That is, the interface caller is determined to be a front-end caller. Fig. 3 schematically shows a timing diagram of a first user type invocation interface according to an embodiment of the application. As shown in fig. 3, the front-end caller (service B) may first initiate a login request to the service system (service a) that provides the back-end service, and then the processor may verify the account and password in the login data. The account and the password are provided to the front-end caller by an operator of the service system (service a). In the event that the login data, such as an account number and password, is validated, the processor may return a first notification to the interface caller. The first notification is a login credential of the interface caller, and may be a character string generated by encrypting a random number, a user name, and a current timestamp. For example, it may be a token string, and the front-end caller calls the interface by specifying the token in the message header data of the authentication data. Further, after the login request of the front-end caller passes, the interface caller will initiate an interface request to the service system. Then, it may be specified that the front-end caller, when initiating the interface request, passes the login credentials through a first notification for authentication to invoke the interface. Only the first notification needs to be authenticated to request data and no further authentication of the login data is required. Further, the processor may receive an interface request for an interface caller to carry a token. The processor may look up the login data corresponding to this token in a database of the service system providing the back-end service. In the event that it is determined that login data corresponding to this token exists in the database, the processor may further determine whether the interface caller to which the login data corresponds has permission to access the database. In the event that the interface caller is determined to have call permissions, the interface caller is allowed to access the database. The front-end caller can prevent the account number and the password in the login data of the front-end caller from being leaked by further carrying out interface calling in a login verification mode, and the safe calling of the interface is ensured.
In one embodiment, the data processing method further comprises: the interface caller is prohibited from accessing the database if any of the following is satisfied: the first notification of the interface caller is null; the login data corresponding to the first notification does not exist; the interface caller has no call authority.
The processor can verify login data carried in a login request initiated by the interface caller and return a first notification that the login data is verified to the interface caller when the user type of the interface caller is determined to be a front-end caller. Further, the interface caller initiates an interface request to the service system. If so, the processor determines that the first notification of the interface request is empty, i.e., there is no token string present in the message header data. Then the processor may prohibit the interface caller from accessing the database. The processor may also prohibit the interface caller from accessing the database if the processor determines that the first notification of the interface request is not empty, but the login data corresponding to the token is not found in the provisioning database. When the interface request of the interface caller meets the condition that the first notification is not empty and the login data corresponding to the token exists, but the processor determines that the corresponding interface caller does not have the calling authority according to the token, the interface caller can be prohibited from accessing the database. Thus, multiple verifications of the data can prohibit illegal callers from calling the interface to access the database.
In one embodiment, verifying the verification data according to the verification mode corresponding to the user type includes: under the condition that the user type is determined to be a second user type, signature data included in the verification data are obtained and verified; in the event that the validation data is validated, allowing the interface caller to access the database comprises: if the signature data passes the verification, returning a second notice that the signature data passes the verification to the interface caller; and the receiving interface caller calls a data access interface of the database according to the second notification so as to allow the interface caller to access the database.
And the processor determines the user type of the interface caller as a second user type under the condition that the message header data comprises the user identification. That is, the interface caller is determined to be a back-end caller. Fig. 4 schematically shows a sequence diagram of a second user type invocation interface according to an embodiment of the application. As shown in fig. 4, the back-end caller (service B) may first initiate an interface request to the service system (service a) providing the back-end service, and then the processor may perform authentication with the authentication data carried in the interface request. Specifically, the processor may acquire signature data included in the verification data to verify. The signature data refers to parameters calculated by an interface caller according to signature of verification data such as own user identification, key data corresponding to the user identification, a timestamp, user information and the like, is contained in the verification data carried by the interface request, and is transmitted to a service system providing back-end service through message header data. Signature data and a user identifier in message header data can be read, and the user identifier is signed according to the same signature algorithm, so that the signature data can be verified in a comparison mode. And the processor returns a second notice of passing the verification to the back-end caller when determining that the signature data passes the verification. And after receiving the second notification, the back-end caller calls a data access interface of the database according to the second notification. At this point, the processor may allow the back-end caller to access the database.
In one embodiment, the verification data further includes user information, and the obtaining signature data included in the verification data and verifying includes: determining key data corresponding to the user identification; acquiring a timestamp included in the verification data, wherein the timestamp is the current time acquired by an interface caller when the interface caller initiates an interface request; generating corresponding standard signature data according to the user identification, the key data, the timestamp and the user information by adopting a signature algorithm the same as that of the interface caller; in the case where the signature data agrees with the standard signature data, it is determined that the verification data is verified.
The user information refers to a request parameter requestParam in the verification data, wherein the request parameter requestParam contains user account information of an interface caller. For example, the username of the interface caller. When the back-end caller initiates an interface request, the back-end caller transmits the message header data to the user identifier of the back-end caller of the service system providing the back-end service. The processor may read the user-identified field value, i.e., read the cross-session-client-id field value clientId, from the message header data. And the back-end caller can determine the current time stamp of the own system when initiating the interface request. The timestamp refers to the current time that the interface caller acquired when initiating the interface request. The key data, clientSecret, may be matched to the clientId. The clientId and clientSecret can be used to prove the identity of the client and the server can know which client is accessing. The interface caller can sign according to the field value of the user identifier, the key data corresponding to the field value of the user identifier, the time stamp, the user information and other verification data to calculate the signature data. The service system can be assigned to the back-end caller user identifier and the key data corresponding to the user identifier, and store the key data in the database of the service system. The back-end caller can transmit the timestamp, the user information, the user identifier and the signature data to the service system when calling the interface. The processor may read the user identification and timestamp from the message header data and find the corresponding key data from the database according to the user identification. Further, the processor may generate corresponding standard signature data from the user identifier, the key data, the timestamp, and the user information using the same signature algorithm as the interface caller. In the case where the signature data agrees with the standard signature data, it is determined that the verification data is verified.
The data processing method further comprises: the interface caller is prohibited from accessing the database if any of the following is satisfied: verifying that signature data and/or a timestamp are not included in the data; key data corresponding to the user identification is not searched in a service system providing the back-end service; the signature data is not consistent with the standard signature data.
The processor may verify the verification data carried in the interface request initiated by the interface caller, when it is determined that the user type of the interface caller is a back-end caller. The processor can search in the data of the service system providing the back-end service through the user identifier, and forbid the back-end caller from accessing the database under the condition that the database does not have the key data corresponding to the user identifier. If there is key data corresponding to the user identification in the database, the processor may read the timestamp from the message header data. If the processor determines that the message header data does not have a timestamp, the back-end caller is also prohibited from accessing the database. Further, if the processor determines that the key data corresponding to the user identifier exists in the database and the timestamp exists in the message header data, the processor may obtain the user information, i.e., the request parameter, in the verification data. Then, the back-end caller reads, from the message header data, signature data calculated by the back-end caller signing the message based on the user identifier assigned by the service system, key data corresponding to the user identifier, a time stamp, and verification data such as user information. And, the back-end caller will pass the signature data to the service system. If the processor determines that the signature data does not exist in the verification data, the back-end caller is prohibited from accessing the database. If the signature data exists in the verification data, the processor signs the signature by adopting the same signature algorithm according to the user identifier transmitted by the back-end caller, the key data matched with the user identifier in the database, the time stamp and the user information so as to calculate the standard signature data. If the signature data does not match the standard signature data, the back-end caller is prohibited from accessing the database. When the back-end caller calls the interface, the user information of the current interface caller is transmitted in the request parameter. For example, the user information may be a user name. Moreover, the verification data can be signed, so that the account information of the caller can be prevented from being falsified.
In one embodiment, as shown in fig. 5, a schematic diagram of steps of a data processing method for a database according to the present application is schematically shown. As shown in fig. 5, in an embodiment of the present application, there is provided a data processing method for a database, including the following steps:
s501, determining whether a cross-session-client-id field exists in the http header, if so, executing S502; if not, go to step S512.
S502, reading a cross-session-client-id field value from the http header.
S503, determining whether the database has a clientSecret matched with the clientId, if yes, executing S504; if not, executing S511.
S504, reading the timestamp from the http header.
S505, determining whether a timestamp exists, if yes, executing S506; if not, S511 is executed.
S506, acquiring a request parameter requestParam.
S507, reading sign 1 in the http header, determining whether the sign 1 exists, and if so, executing S508; if not, S511 is executed.
The signature data sign 1 is calculated by the back-end caller by using the SHA256 algorithm according to the clientId, the clientSecret, the timestamp and the request parameter requestParam distributed by the service system.
S508, signing the clientId, the clientSecre matched with the clientId in the database, the timetag and the requestParam by adopting an SHA256 algorithm to obtain sign 2.
S509, determining whether sign 1 is consistent with sign 2, if yes, executing S510; if not, S511 is executed.
And S510, determining that the verification data of the interface caller passes the verification, and returning the interface data to the interface caller to access the database.
S511, forbidding the interface caller from calling the interface to access the database.
S512, reading the token field value from the http header.
S513 determines whether the token is empty, if not, executes S514, and if so, executes S511.
And S514, inquiring the login data of the front-end caller from the redis database according to the token.
S515, determine whether the register data of the front end caller exists in the redis database. If yes, go to S516. If not, S511 is executed.
S516, determining whether the interface caller has access authority according to the login data searched in the database, and if so, executing S510; if not, S511 is executed.
As shown in fig. 5, when receiving an interface request initiated by an interface caller, a processor may obtain authentication data carried in the interface request. The verification data includes message header data, http header, and the processor may determine whether a cross-session-client-id field exists in the http header. The cross-session-client-id field is the user identifier. And under the condition that cross-session-client-id fields exist in the http header, determining the interface caller at the moment as a back-end caller. The processor may read the field value clientId of the cross-session-client-id field from the http header. The service system can be distributed to a back-end caller clientId and key data clientSecret, and when the back-end caller calls an interface, the back-end caller transmits the clientId information through message header data http header but does not transmit the clientSecret information. And after reading the clientrD of the back-end caller in the http header, the processor searches the corresponding clientSecret in the database according to the clientrD. If it is determined that there is no clientSecret matching the clientId in the database, the interface caller is prohibited from calling the interface to access the database. And if the corresponding clientSecret in the database exists, reading the timestamp in the http header. And if the http header does not have the timestamp, prohibiting the interface caller from calling the interface to access the database. If the timestamp exists, the processor can obtain a request parameter requestParam in the verification data at this time, and read signature data sign 1 from the http header. Signature data sign 1 is calculated by the back-end caller according to the clientId, the clientSecret, the timestamp and the request parameter requestParam distributed by the service system. Further, in the case that the processor determines that the signature data sign 1 exists, the processor signs the obtained clientId, the clientSecret paired with the clientId in the database, the timestamp and the request parameter requestParam to obtain standard signature data sign 2. In particular, the signature algorithm may be the SHA256 algorithm. Then, the processor may determine that the verification data is verified, determine that the verification data of the interface caller is verified, and return the interface data to the interface caller to access the database, in a case where it is determined that the signature data sign 1 is identical to the standard signature data sign 2.
And under the condition that the http header does not have cross-session-client-id fields, determining the interface caller at the moment as a front-end caller. The processor may read the token field value from an http header included in the verification data. If the processor determines that the token is empty, the interface caller is prohibited from calling the interface to access the database. And if the token is determined not to be empty, inquiring the login data of the front-end caller in a redis database according to the token. If the register data of the previous caller corresponding to the token does not exist in the redis database, the interface caller is prohibited from calling the interface to access the database. If yes, determining whether the interface caller has the access right according to the login data searched in the database. If the processor determines that the interface caller does not have access rights, the interface caller is prohibited from calling the interface to access the database. If the interface caller meets the above conditions and has access authority, the verification data of the interface caller is determined to pass verification, and the interface data is returned to the interface caller to access the database.
In one embodiment, the data processing method further comprises: acquiring an access white list, wherein the access white list comprises an allowed interface address allowing access to a database; determining a request address carried by an interface request under the condition that the verification data passes verification; allowing the interface caller to access the database if the request address is included in the allowed interface address; if the request address is not included in the permitted interface address, the interface caller is prohibited from accessing the database.
In order to support intranet calls only, that is, support only backend caller calls, some interfaces of a service system providing backend services limit front-end caller calls in some scenarios. Alternatively, only front-end caller calls are supported and back-end caller calls are restricted. The access white list only supporting intranet call can be configured in a database or a configuration file, and the access white list comprises allowed interface addresses allowing access to the database. The allowed interface address includes one or more of the following addresses, which are used to limit the interface caller carrying the interface address except the allowed interface address from calling the interface.
For example, in the case where the configuration supports only a portion of the back-end callers where interface calls may be made. And the processor identifies that the user identifier exists in the message header data, and determines that the interface caller is a second user type, namely a back-end caller. Then, the processor may complete the verification process in the above scheme first in a verification manner for the back-end caller according to the signature authentication. After determining that the verification data passes the verification, the processor may further determine a request address carried in the interface caller-originated interface request. It is determined whether the request address is present in the allowed interface address. If so, the interface caller is allowed access to the database. If not, the interface caller is prohibited from accessing the database. Also, when it is necessary to configure only a portion of the front-end callers to be able to make interface calls and to restrict the front-end or back-end interface calls. The above method may be adopted. Specifically, a mode of configuring an allowed interface address only supporting intranet call in a database or a configuration file can be replaced by a mode of self-defined annotation in java language.
By the technical scheme, the interface call initiates an interface request to a service system user providing the back-end service, and the user type of the interface caller is distinguished as a front-end caller or a back-end caller according to the user identification in the verification data carried in the interface request. And for the login request initiated by the front-end caller, under the condition that the login data in the login request is verified and passes the verification, returning the login data to the front-end caller to send an interface request carrying the first notification to the front-end caller for interface calling. For a back-end caller, a service system providing back-end services may be assigned to the back-end caller user identification and key data matching the user identification. The back-end caller may sign the user identification, key data, timestamp, and user information to obtain signature data. The service system can acquire the user identifier, the timestamp and the signature data transmitted by the back-end caller through the message header data, search the key data matched with the user identifier in the database through the user identifier, and acquire the user information in the verification data. And signing by adopting the same signature algorithm according to the user identifier, the key data searched in the database, the time stamp and the user information to obtain standard signature data. In the event that the signature data is determined to be consistent with the standard signature data, the back-end caller is allowed to make calls to the interface. Furthermore, the allowed interface address only supporting intranet calling can be configured in a database or a configuration file, and partial callers can be limited from calling the interface. The front-end caller and the back-end caller are distinguished through the user identification, and the service provider can conveniently determine the user account of the back-end caller. In addition, different calling services can be provided for different callers, and the efficiency of interface calling is improved. And in the process of verifying the verification data, if the verification condition is not met, the interface caller is prohibited from accessing the database, and the interface is prevented from being illegally called, so that the safety of interface calling is ensured. The back-end caller can prevent the user account from being tampered by transmitting the user information to the service system and signing the user information.
FIG. 2 is a flow diagram that illustrates a data processing method for a database, according to one embodiment. It should be understood that, although the steps in the flowchart of fig. 2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in fig. 2 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
Fig. 6 schematically shows a block diagram of a data processing system for a database according to an embodiment of the present application. Referring to fig. 6, in an embodiment of the present application, there is further provided a data processing system 600, including:
a first terminal 602, configured to initiate, by an interface caller of a first user type, an interface request for accessing a database of a service system to the service system providing a backend service;
a second terminal 604, configured to initiate, by an interface caller of a second user type, an interface request for accessing a database of a service system to the service system providing a backend service; and
the processor 606 is configured to perform the data processing method for the database.
In one embodiment, as shown in fig. 7, a data processing apparatus 700 for a database is provided, which includes an interface request obtaining module 702, a user type determining module 704, and a data verifying module 706, wherein:
an interface request obtaining module 702, configured to obtain an interface request initiated by an interface caller, where the interface request carries verification data.
A user type determining module 704, configured to determine the user type of the interface caller according to the user identifier in the verification data.
And the data verification module 706 is configured to verify the verification data according to a verification manner corresponding to the user type. In the case of verification of the verification data, the interface caller is allowed to access the database.
In one embodiment, the verification data includes message header data. The user type determining module 704 is further configured to determine that the user type is the first user type if the user identifier is not included in the message header data; and determining the user type as a second user type under the condition that the message header data comprises the user identification.
In one embodiment, the authentication data further comprises login data. The data verification module 706 is further configured to verify the login data if it is determined that the user type is the first user type; in the event that the validation data is validated, allowing the interface caller to access the database comprises: under the condition that the login data passes the verification, returning a first notice that the login data passes the verification to the interface caller; receiving a data access interface of the database called by the interface caller according to the first notice; and searching login data corresponding to the first notification in a service system providing the back-end service, and allowing the interface caller to access the database under the condition that the interface caller is determined to have the calling authority.
In one embodiment, the data validation module 706 is further configured to prohibit the interface caller from accessing the database if any of the following is satisfied: the first notification of the interface caller is null; the login data corresponding to the first notification does not exist; the interface caller has no call authority.
In one embodiment, the data verification module 706 is further configured to, in a case that the user type is determined to be the second user type, obtain and verify signature data included in the verification data; in the case that the verification data passes the verification, allowing the interface caller to access the database comprises: if the signature data passes the verification, returning a second notice that the signature data passes the verification to the interface caller; and the receiving interface caller calls a data access interface of the database according to the second notification so as to allow the interface caller to access the database.
In one embodiment, the verification data further comprises user information. The data verification module 706 is further configured to determine key data corresponding to the user identifier; acquiring a timestamp included in the verification data, wherein the timestamp is the current time acquired by an interface caller when the interface caller initiates an interface request; generating corresponding standard signature data according to the user identification, the key data, the timestamp and the user information by adopting a signature algorithm the same as that of the interface caller; in the case where the signature data agrees with the standard signature data, it is determined that the verification data is verified.
In one embodiment, the data validation module 706 is further configured to prohibit the interface caller from accessing the database if any of the following is satisfied: verifying that signature data and/or a timestamp are not included in the data; key data corresponding to the user identification is not searched in a service system providing the back-end service; the signature data is not consistent with the standard signature data.
In one embodiment, the data processing apparatus 700 for a database further includes an interface address confirmation module, configured to obtain an access white list, where the access white list includes allowable interface addresses allowing access to the database; determining a request address carried by an interface request under the condition that the verification data passes verification; allowing the interface caller to access the database under the condition that the request address is included in the allowable interface address; if the request address is not included in the permitted interface address, the interface caller is prohibited from accessing the database.
The data processing device for the database comprises a processor and a memory, wherein the interface request acquisition module, the user type determination module, the data verification module and the like are stored in the memory as program units, and the processor executes the program modules stored in the memory to realize corresponding functions.
The processor comprises a kernel, and the kernel calls the corresponding program unit from the memory. The kernel can be set to be one or more, and the data processing method for the database is realized by adjusting the kernel parameters.
The memory may include volatile memory in a computer readable medium, random Access Memory (RAM) and/or nonvolatile memory such as Read Only Memory (ROM) or flash memory (flash RAM), and the memory includes at least one memory chip.
An embodiment of the present application provides a storage medium, on which a program is stored, which when executed by a processor implements the above-described data processing method for a database.
The embodiment of the application provides a processor, wherein the processor is used for running a program, and the data processing method for the database is executed when the program runs.
In one embodiment, a computer device is provided, which may be a server, and the internal structure thereof may be as shown in fig. 8. The computer apparatus includes a processor a01, a network interface a02, a memory (not shown in the figure), and a database (not shown in the figure) connected through a system bus. Wherein the processor a01 of the computer device is arranged to provide computing and control capabilities. The memory of the computer apparatus includes an internal memory a03 and a nonvolatile storage medium a04. The nonvolatile storage medium a04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory a03 provides an environment for running the operating system B01 and the computer program B02 in the nonvolatile storage medium a04. The database of the computer device is used for storing data for the data processing method of the database. The network interface a02 of the computer apparatus is used for communicating with an external terminal through a network connection. The computer program B02 is executed by the processor a01 to implement a data processing method for a database.
Those skilled in the art will appreciate that the architecture shown in fig. 8 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
The embodiment of the application provides equipment, which comprises a processor, a memory and a program stored on the memory and capable of running on the processor, wherein the processor executes the program to realize the steps of the data processing method for the database.
The present application further provides a computer program product adapted to perform a program of initializing data processing method steps for a database when executed on a data processing device.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.
The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims (11)

1. A data processing method for a database, wherein the database is a database of a service system providing a backend service, the data processing method comprising:
acquiring an interface request initiated by an interface caller, wherein the interface request carries verification data;
determining the user type of the interface caller according to the user identification in the verification data;
verifying the verification data according to a verification mode corresponding to the user type;
and allowing the interface caller to access a database if the verification data passes verification.
2. The data processing method of claim 1, wherein the validation data comprises message header data, and wherein the determining the user type of the interface caller according to the user identifier in the validation data comprises:
determining the user type as a first user type under the condition that the message header data does not comprise the user identification;
and under the condition that the message header data comprises the user identification, determining the user type as a second user type.
3. The data processing method for the database according to claim 2, wherein the verification data further includes login data, and the verifying the verification data according to the verification manner corresponding to the user type includes:
verifying the login data if the user type is determined to be a first user type;
in the event that the validation data is validated, allowing the interface caller to access a database comprises:
under the condition that the login data passes the verification, returning a first notice that the login data passes the verification to the interface caller;
receiving a data access interface of the database called by the interface caller according to the first notification;
and searching login data corresponding to the first notification in the service system providing the back-end service, and allowing the interface caller to access a database under the condition that the interface caller is determined to have the calling authority.
4. The data processing method for a database of claim 3, further comprising:
prohibiting the interface caller from accessing the database if any of:
a first notification of the interface caller is null;
login data corresponding to the first notification does not exist;
the interface caller has no calling authority.
5. The data processing method for the database according to claim 2, wherein the verifying the verification data according to the verification manner corresponding to the user type comprises:
under the condition that the user type is determined to be a second user type, signature data included in the verification data are obtained and verified;
in the event that the validation data is validated, allowing the interface caller to access a database comprises:
if the signature data passes the verification, returning a second notice that the signature data passes the verification to the interface caller;
and receiving a data access interface of the database called by the interface caller according to the second notification so as to allow the interface caller to access the database.
6. The data processing method for a database according to claim 5, wherein the verification data further includes user information, and the acquiring and verifying signature data included in the verification data includes:
determining key data corresponding to the user identification;
acquiring a timestamp included in the verification data, wherein the timestamp is the current time acquired by the interface caller when the interface request is initiated;
generating corresponding standard signature data according to the user identification, the key data, the timestamp and the user information by adopting a signature algorithm the same as that of the interface caller;
and determining that the verification data is verified if the signature data is consistent with the standard signature data.
7. The data processing method for a database according to claim 6, wherein the data processing method further comprises:
prohibiting the interface caller from accessing the database if any of:
the verification data does not comprise signature data and/or a time stamp;
key data corresponding to the user identification is not searched in the service system for providing the back-end service;
the signature data is inconsistent with the standard signature data.
8. The data processing method for a database according to claim 1, wherein the data processing method further comprises:
obtaining an access white list, wherein the access white list comprises an allowed interface address allowing access to the database;
determining a request address carried by the interface request under the condition that the verification data passes verification;
allowing the interface caller to access a database if the request address is included in the allowed interface address;
and if the request address is not included in the allowed interface address, prohibiting the interface caller from accessing the database.
9. A processor configured to perform the data processing method for a database according to any one of claims 1 to 8.
10. A machine-readable storage medium having instructions stored thereon, which when executed by a processor causes the processor to be configured to perform a data processing method for a database according to any one of claims 1 to 8.
11. A data processing system for a database, the data processing system comprising:
the first terminal is used for initiating an interface request for accessing a database of a service system to the service system providing the back-end service by an interface caller of a first user type;
the second terminal is used for initiating an interface request for accessing a database of a service system to the service system providing the back-end service by an interface caller of a second user type; and
the processor of claim 9.
CN202210882461.0A 2022-07-26 2022-07-26 Data processing method and system for database, storage medium and processor Pending CN115361173A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210882461.0A CN115361173A (en) 2022-07-26 2022-07-26 Data processing method and system for database, storage medium and processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210882461.0A CN115361173A (en) 2022-07-26 2022-07-26 Data processing method and system for database, storage medium and processor

Publications (1)

Publication Number Publication Date
CN115361173A true CN115361173A (en) 2022-11-18

Family

ID=84032158

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210882461.0A Pending CN115361173A (en) 2022-07-26 2022-07-26 Data processing method and system for database, storage medium and processor

Country Status (1)

Country Link
CN (1) CN115361173A (en)

Similar Documents

Publication Publication Date Title
US11323260B2 (en) Method and device for identity verification
JP6651530B2 (en) Method and apparatus for identifying a user ID
CN112333198A (en) Secure cross-domain login method, system and server
CN111931154B (en) Service processing method, device and equipment based on digital certificate
CN111030812A (en) Token verification method, device, storage medium and server
WO2019015516A1 (en) Methods and apparatus for authentication of joint account login
CN111880919B (en) Data scheduling method, system and computer equipment
CN106549919B (en) Information registration and authentication method and device
RU2734027C2 (en) Method and device for preventing an attack on a server
CN113472716A (en) System access method, gateway device, server, electronic device, and storage medium
CN116484338A (en) Database access method and device
CN110753018A (en) Login authentication method and system
CN111355730A (en) Platform login method, device, equipment and computer readable storage medium
CN108965335B (en) Method for preventing malicious access to login interface, electronic device and computer medium
CN113065120B (en) Interface calling authentication method and device, electronic equipment and readable storage medium
CN115361173A (en) Data processing method and system for database, storage medium and processor
CN110457959B (en) Information transmission method and device based on Trust application
CN113691485B (en) Micro-service platform access method and related device thereof
CN112866265A (en) CSRF attack protection method and device
US11977620B2 (en) Attestation of application identity for inter-app communications
CN112583777B (en) Method and device for realizing user login
CN114978681B (en) Service application authorization method and device based on block chain and processor
CN112822007B (en) User authentication method, device and equipment
CN110912697B (en) Scheme request verification method, device and equipment
CN113407917A (en) Security verification method, related equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination