Transaction verification method, transaction system, client, device, medium and product

Abstract

The embodiment of the invention provides a transaction verification method, a transaction system, a client, equipment, a medium and a product, and the method comprises the steps: a transaction node in the transaction system receives a login request which is transmitted by the client and comprises a login password of a first user, and verifying the login password of the first user based on the local password of the first user obtained by query under the transaction node, and returning a verification result to the client. According to the scheme of the invention, each transaction node comprises the local passwords of the plurality of users, and each transaction node can independently respond to the login request of the user belonging to the node or belonging to other nodes, so that the login of the user is prevented from being verified by using a single transaction node, and the reliability of financial transactions is improved.

Description

Technical Field

[0001] This application relates to the field of financial technologies, and in particular, to a transaction verification method, a transaction system, a client, a device, a medium, and a product. Background Art

[0002] With the rapid development of information technology and the Internet, financial transactions such as securities transactions, stock transactions, foreign exchange transactions, and other derivative transactions have become an indispensable part of modern economic activities. Among them, the user password data stored in the financial transaction system is large in quantity, high in complexity, and extremely high in security requirements. Therefore, these password data need to be effectively managed and protected.

[0003] In a current financial transaction system, user passwords are stored in the transaction nodes to which the users belong, and users perform operations such as user login and transaction settlement through these transaction nodes. Since each transaction node stores and manages the transaction passwords of the customers of this node respectively, when a transaction node fails, the users under this transaction node cannot perform login verification and further transactions, reducing the reliability of the transaction system. Therefore, the current problem to be solved is how to improve the reliability of financial transactions. Summary of the Invention

[0004] Embodiments of this application provide a transaction verification method, a transaction system, a client, a device, a medium, and a product to improve the reliability of financial transactions.

[0005] In a first aspect, embodiments of this application provide a transaction verification method applied to a transaction system. The transaction system includes multiple transaction nodes, and each transaction node includes local passwords of multiple users. The method includes: a transaction node receives a login request sent by a client, the login request includes the login password of a first user, the first user is any one of the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; the transaction node verifies the login password of the first user based on the local password of the first user queried under this transaction node, and returns a verification result to the client.

[0006] In a possible implementation manner, each transaction node further includes transaction node information to which multiple users belong; returning the verification result to the client specifically includes: if the verification is passed, the transaction node queries and obtains the transaction node information to which the first user belongs under this transaction node; the transaction node returns the verification result to the client, and the verification result includes the token of the first user and the transaction node information to which the first user belongs.

[0007] In a possible implementation, the method further includes: the trading node receives a delegation request sent by the client, where the delegation request includes the token of the second user, and the second user is any user among the users belonging to the trading node; the trading node determines the login status of the second user based on the token of the second user and returns a delegation response.

[0008] In a possible implementation, the token includes: the identifier of the first user, the session number assigned by the trading node to the first user, a timestamp, and the index of the first user in the trading node.

[0009] In a possible implementation, the intervals of the session numbers assigned by different trading nodes to the first user are different.

[0010] In a possible implementation, the method further includes: the trading node encrypts the token of the first user; the trading node determines the login status of the second user based on the token of the second user, including: the trading node decrypts the token of the second user and performs a legality verification: verifying the legality of at least one piece of data among the identifier, session number, timestamp, and index; if the trading node successfully decrypts the token of the second user and the legality verification is successful, it is determined that the login status of the second user is passed.

[0011] In a possible implementation, the trading system further includes a central node, and the local passwords of multiple users are included under the central node; the method further includes: the central node receives an update request sent by the client, where the update request includes the login password and the update password of the first user; the central node verifies the login password of the first user based on the local password of the first user queried under this central node, and if the verification is passed, it updates the local password of the first user under this central node to the update password and synchronizes the update password to each trading node, so that each trading node updates the local password of the first user under this trading node to the update password.

[0012] In a possible implementation, the update password sent by the client is the password encrypted based on the first encryption algorithm; before the central node updates the local password of the first user under this central node to the update password, it further includes: the central node encrypts the update password based on the second encryption algorithm; where the first encryption algorithm is different from the second encryption algorithm.

[0013] Second aspect, an embodiment of the present application provides a transaction verification method, which is applied to a client. The method includes: sending a login request to a transaction node in a transaction system; wherein, the transaction system includes multiple transaction nodes, and each transaction node includes local passwords of multiple users; the login request includes the login password of a first user, the first user is any one of the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; receiving a verification result returned by the transaction node; wherein, the verification result is obtained by the transaction node verifying the login password of the first user based on the local password of the first user queried under this transaction node.

[0014] In a possible implementation manner, the verification result includes the token of the first user and the transaction node information to which the first user belongs; the method further includes: according to the transaction node information to which the first user belongs, sending a delegation request to the transaction node to which the first user belongs, the delegation request includes the token of the first user; receiving a delegation response returned by the transaction node to which the first user belongs; wherein the delegation response is returned by the transaction node to which the first user belongs after determining the login status of the first user based on the token of the first user.

[0015] In a possible implementation manner, the method further includes: obtaining the load status of each transaction node; sending a login request to a transaction node in the transaction system, including: based on the load status of each transaction node, sending a login request to a transaction node in the transaction system.

[0016] In a possible implementation manner, the transaction system further includes a central node, and the central node includes local passwords of multiple users; the method further includes: sending an update request to the central node; wherein, the update request includes the login password and the update password of the first user.

[0017] In a possible implementation manner, before sending the update request to the central node, the method further includes: encrypting the update password based on a first encryption algorithm.

[0018] Third aspect, an embodiment of the present application provides a transaction system. The transaction system includes multiple transaction nodes, and each transaction node includes local passwords of multiple users; wherein, the transaction node is configured to receive a login request sent by a client, the login request includes the login password of a first user, the first user is any one of the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; the transaction node is further configured to verify the login password of the first user based on the local password of the first user queried under this transaction node, and return a verification result to the client.

[0019] Fourthly, an embodiment of the present application provides a client, which is used to: send a login request to a trading node in a trading system; wherein, the trading system includes multiple trading nodes, and each trading node includes local passwords of multiple users; the login request includes the login password of a first user, the first user is any one of the multiple users, and the multiple users include users belonging to the trading node and other trading nodes; receive a verification result returned by the trading node; wherein, the verification result is obtained by the trading node based on the local password of the first user queried under this trading node to verify the login password of the first user.

[0020] Fifthly, an embodiment of the present application provides an electronic device, including: a memory, a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the processor executes the first aspect and / or various possible implementation manners of the first aspect as above.

[0021] Sixthly, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, they are used to implement the first aspect and / or various possible implementation manners of the first aspect as above.

[0022] Seventhly, an embodiment of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the first aspect and / or various possible implementation manners of the first aspect as above.

[0023] In the transaction verification method, transaction system, client, device, medium and product provided by the embodiments of the present application, the method includes: a trading node in the trading system receives a login request sent by the client, which includes the login password of a first user, verifies the login password of the first user based on the local password of the first user queried under this trading node, and returns a verification result to the client. In the solution of the present application, each trading node includes local passwords of multiple users, and each trading node can independently respond to login requests of users belonging to this node or other nodes, avoiding using a single trading node to verify user logins, thereby improving the reliability of financial transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings here are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0025] Figure 1 It is a schematic flowchart of the transaction verification method provided by the embodiment of the present application;

[0026] Figure 2Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0027] Figure 3 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0028] Figure 4 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0029] Figure 5 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0030] Figure 6 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0031] Figure 7 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0032] Figure 8 Schematic flowchart of the transaction verification method provided by an embodiment of this application;

[0033] Figure 9 Schematic interaction diagram of the transaction system provided by an embodiment of this application;

[0034] Figure 10 Schematic interaction diagram of the transaction system provided by an embodiment of this application;

[0035] Figure 11 Schematic structural diagram of the electronic device provided by an embodiment of this application.

[0036] Through the above-mentioned drawings, specific embodiments of this application have been shown, and there will be more detailed descriptions hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of this application in any way, but to illustrate the concept of this application to those skilled in the art by referring to specific embodiments. Detailed implementation manners

[0037] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with this application. On the contrary, they are merely examples of devices and methods consistent with some aspects of this application.

[0038] It should be noted that the brief description of the terms in this application is only for the convenience of understanding the following described embodiments, rather than intending to limit the embodiments of this application. Unless otherwise specified, these terms should be understood in their ordinary and common meanings. In this application, the terms "comprising" and "having" in the specification, claims and the above-mentioned drawings, and any variations thereof, are intended to cover but not exclusively include. For example, a product or device comprising a series of components does not necessarily have to be limited to those components clearly listed, but may include other components not clearly listed or inherent to these products or devices. The term "module" used in this application refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or a combination of hardware or / and software code that can perform functions related to that element.

[0039] With the rapid development of information technology and the Internet, financial transactions such as securities trading, stock trading, foreign exchange trading, and other derivative transactions have become an indispensable part of modern economic activities. Behind these trading activities is a complex and huge financial trading system. In this system, the storage and management of user password data play a crucial role. Since financial transactions involve a large amount of capital flow and sensitive information, the security requirements for password data are extremely high. Therefore, how to effectively manage and protect this password data has become a core issue in the design of financial trading systems.

[0040] Currently, the financial trading systems in related technologies adopt a distributed password management method, that is, user passwords are stored in the trading nodes to which the users belong. Users perform business operations such as logging in and trading settlement through the trading nodes to which they belong. The advantage of this method is that each trading node can independently manage the password data of its customers, reducing the risk of single-point failure. However, this method also brings some challenges. When a customer needs to migrate between different trading nodes, the password data must also be migrated accordingly. This not only increases the complexity of management and the difficulty of operation, but also reduces the flexibility and response speed of the system. Additionally, there is another solution to centrally store the trading passwords of multiple nodes in an independent node for management. The password verification operations of all trading nodes are carried out on this independent node. This centralized management method simplifies the password data migration problem because users no longer need to frequently migrate password data when switching between different trading nodes. However, the disaster tolerance of the centralized management solution is relatively low. Once the independent node fails, the password verification function of the entire system will be affected. At the same time, the independent node needs to handle a large number of password verification requests, increasing the load requirements for the independent node.

[0041] The technical content provided by this application aims to solve the above-mentioned technical problems in the related art. In the transaction verification method, transaction system, client, device, medium, and product provided by the embodiments of this application, the method includes: a transaction node in the transaction system receives a login request sent by the client, which includes the login password of the first user. The local password of the first user obtained by querying under this transaction node is used to verify the login password of the first user, and the verification result is returned to the client. In the solution of this application, the local passwords of multiple users are included under each transaction node, and each transaction node can independently respond to the login requests of users belonging to this node or other nodes, avoiding the use of a single transaction node to verify user logins, thereby improving the reliability of financial transactions.

[0042] The technical content of this application can be used in scenarios such as securities brokerage, investment banking, and asset management. It can flexibly manage user logins between different business platforms without the need for cumbersome password migrations, thereby improving operation efficiency and security, and ensuring service continuity by enhancing the disaster tolerance of the system, improving the customer experience and market competitiveness.

[0043] The following uses specific embodiments to elaborate in detail on the technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems. These several specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0044] Figure 1 It is a schematic flowchart of the transaction verification method provided by the embodiments of this application. The method of this embodiment is applied to a transaction system. The transaction system includes multiple transaction nodes, and the local passwords of multiple users are included under each transaction node. As Figure 1 shown, the transaction verification method includes:

[0045] Step 101: The transaction node receives a login request sent by the client. The login request includes the login password of the first user, and the first user is any one of multiple users. The multiple users include users belonging to this transaction node and other transaction nodes;

[0046] Step 102: The transaction node verifies the login password of the first user based on the local password of the first user obtained by querying under this transaction node, and returns the verification result to the client.

[0047] In practical applications, the trading system can be a financial trading system such as an inter-bank payment and settlement system, a securities exchange, a foreign exchange trading platform, etc. The corresponding trading nodes can be bank servers, securities company servers, and payment gateways. Optionally, the trading system can also be a blockchain network, and the corresponding trading nodes are blockchain nodes. Exemplarily, the trading node can be a general-purpose calculator, a server, or a dedicated hardware device, etc., which is responsible for processing user requests, verifying user identities, executing trading instructions, and other functions. For example, a trading node can be composed of at least one server, and multiple trading nodes may be distributed in different geographical locations to improve the reliability and response speed of the system. On the other hand, in practical applications, the client in this example can be an application program based on different operating systems such as a desktop application program or a mobile application program. Optionally, the client can also be a web browser, or an API (Application Programming Interface) client connected to other systems.

[0048] Exemplarily, the login request received by the trading node can come from a user. Specifically, the login request usually includes a user identifier (such as a username or user ID) and a login password, which are used to identify and verify the user's identity in the trading node. In this example, multiple users under different trading nodes are the same, and each trading node includes local passwords of users belonging to this trading node and other trading nodes. In an exemplary scenario, the login request received by the trading node can also be a login request from the client forwarded by other trading nodes to improve the flexibility of processing login requests.

[0049] Exemplarily, in addition to storing the local password of the user, the transaction node can also store other information of the users belonging to the transaction node for subsequent transactions. For example, the user's account information such as account balance, account status, account type, etc., or store the user's historical transaction records such as transaction time, transaction amount, counterparty, etc., or store the user's role in the system and its corresponding permission settings. In practical applications, each transaction node can include one or more databases to store the above data. Exemplarily, when storing the local password of the user, a secure hash algorithm (such as bcrypt, Argon2) is used to hash the password and store the hash value instead of the plaintext password to improve the security of the system. In this example, the transaction node verifies the login password of the first user based on the local password of the first user obtained by querying under this transaction node, that is, determines whether the local password of the first user is the same as the login password of the first user. Optionally, when the user updates the password, the local password of the user under the transaction node can also be updated regularly. Exemplarily, when the user updates the password, the update request propagates in the distributed database to ensure the consistency of all node data. Optionally, a centralized authentication and authorization service can also be used to manage the user's password and authentication information. In practical applications, the user password update request is sent to the centralized service, and this service is responsible for notifying the relevant transaction nodes to update.

[0050] The transaction verification method provided by the embodiment of the present application includes: the transaction node in the transaction system receives a login request sent by the client, including the login password of the first user, verifies the login password of the first user based on the local password of the first user obtained by querying under this transaction node, and returns the verification result to the client. In the solution of the present application, each transaction node includes the local passwords of multiple users, and each transaction node can independently respond to the login requests of users belonging to this node or other nodes, avoiding using a single transaction node to verify the user's login, thereby improving the reliability of financial transactions.

[0051] Figure 2 It is a schematic flowchart of the transaction verification method provided by the embodiment of the present application. Among them, each transaction node also includes transaction node information to which multiple users belong. As Figure 2 shown, on the basis of any example, in step 102, returning the verification result to the client based on the security icon specifically includes:

[0052] Step 201, if the verification passes, the transaction node queries and obtains the transaction node information to which the first user belongs under this transaction node;

[0053] Step 202, the transaction node returns the verification result to the client, and the verification result includes the token of the first user and the transaction node information to which the first user belongs.

[0054] In this example, the trading node queries and obtains the trading node information to which the first user belongs under this trading node through the user ID, account information, or other unique identifiers. In practical applications, the trading node can generate a unique and secure token, such as generating a token using an encryption algorithm, to prevent forgery and replay attacks. It can be understood that both the token of the first user and the trading node information to which the first user belongs in this example are used for subsequent transactions. For example, the client can conduct transactions at the corresponding trading node based on the trading node information of the first user, and the token can ensure that the operations of the user in the trading system are verified. Optionally, during the entire verification process, especially when returning the verification result, ensure that all data is encrypted when transmitted over the network, such as using the TLS (Transport Layer Security) protocol. The solution of this example, where the verification result includes the token of the first user and the trading node information to which the first user belongs, can improve the efficiency and security of the client during subsequent transactions.

[0055] Figure 3 It is a schematic flowchart of the transaction verification method provided by the embodiment of the present application. As Figure 3 shown, on the basis of any example, the transaction verification method further includes:

[0056] Step 301: The trading node receives a delegation request sent by the client. The delegation request includes the token of the second user, and the second user is any user among the users belonging to the trading node;

[0057] Step 302: The trading node determines the login status of the second user based on the token of the second user and returns a delegation response.

[0058] Exemplarily, the entrustment request can be generated by the client based on user manual operations or preset trading strategies. In practical applications, the entrustment request may include: request types such as buy, sell, query, etc., or trading parameters such as trading amount, asset type, quantity, etc. for detailed information, or client information such as the client's device information, IP address, etc. for further security verification. Optionally, if the entrustment request is based on an established session, it may include a session ID or other relevant information. It should be noted that for a trading node, the first user is the user who stores the local password of this user under this trading node, and the second user is the user belonging to this trading node. Therefore, the first user and the second user are only used for distinction. In practical applications, the first user and the second user may be the same user or different users, which is not limited here. The solution of this example ensures the validity of the user identity and the security of trading operations by receiving and verifying the entrustment request sent by the client at the trading node; among them, using the token of the second user to confirm the login status can effectively prevent unauthorized access and operations, thereby improving the security and reliability of the trading process.

[0059] As another example, on the basis of any example, the token includes: the identifier of the first user, the session number assigned by the trading node to the first user, the timestamp, and the index of the first user in the trading node.

[0060] In this example, the identifier of the first user can ensure that the trading node can accurately identify which user the request comes from, preventing identity confusion and unauthorized access; the session number assigned by the trading node to the first user can be used to track the status and persistence of the session; the timestamp is the specific time information generated for the request, which can be used to verify the timeliness and freshness of the request; the index of the first user in the trading node can be the position or reference of the first user in the database of this trading node to accelerate the retrieval and verification process of user information. The solution of this example not only enhances the security and reliability of the trading process by including a token with multiple elements, but also improves the efficiency of the system and the user experience.

[0061] As another example, on the basis of any example, the ranges of the session numbers assigned by different trading nodes to the first user are different.

[0062] In this example, different ranges of session numbers are assigned to each trading node to ensure that the session IDs are unique among different nodes, avoiding conflicts of session IDs. Exemplarily, through the ranges of session numbers, it is possible to quickly identify which trading node assigns a session, thus simplifying system management and troubleshooting. Exemplarily, the assignment of different ranges can help the system better perform load balancing, ensure that the number of sessions processed by each node is within a reasonable range, and optimize resource utilization. Exemplarily, Table 1 shows the ranges of session numbers corresponding to different trading nodes. As shown in Table 1, the range of session numbers for the trading node numbered 67 is from 0 to 100000000.

[0063] Table 1

[0064] Transaction Node Number Starting Value of Session Number Ending Value of Session Number 67 0 100000000 71 100000000 200000000 81 200000000 300000000

[0065] In the solution of this example, different ranges of session numbers are assigned to the first user by different trading nodes, which can improve session security and simplify the management of session numbers.

[0066] Figure 4 It is a schematic flowchart of the transaction verification method provided for the embodiments of this application. As Figure 4 shown, on the basis of any example, the transaction verification method further includes:

[0067] Step 401: The trading node encrypts the token of the first user;

[0068] In step 302, the trading node determines the login status of the second user based on the token of the second user, including:

[0069] Step 402: The trading node decrypts the token of the second user and performs a legality verification: verifying the legality of at least one piece of data among the identifier, session number, timestamp, and index;

[0070] Step 403: If the trading node successfully decrypts the token of the second user and the legality verification is successful, it is determined that the login status of the second user is passed.

[0071] Exemplarily, the trading node may encrypt the token through a symmetric encryption algorithm such as the AES algorithm or an asymmetric encryption algorithm such as the RSA algorithm. In this example, when performing the legality verification, the legality of the user identifier can be verified by checking whether the user identifier in the token is valid and exists in the system; the legality of the session number can be verified by confirming whether the session number is in the current active session list; the legality of the timestamp can be verified by checking whether the timestamp is within the allowed time window; and the legality of the index can be verified by verifying whether the index of the first user in the trading node is correct. The solution of this example can improve the reliability of the token and further improve the security and effectiveness of the trading process by decrypting and encrypting the token and performing legality verification on the data in the token.

[0072] Figure 5 It is a schematic flowchart of the trading verification method provided by the embodiment of the present application. Among them, the trading system further includes a central node, and the local passwords of multiple users are included under the central node. As Figure 5 shown, based on any example, the trading verification method further includes:

[0073] Step 501, the central node receives an update request sent by the client, and the update request includes the login password and the update password of the first user;

[0074] Step 502, the central node verifies the login password of the first user based on the local password of the first user queried under this central node. If the verification passes, the local password of the first user under this central node is updated to the update password, and the update password is synchronized to each trading node, so that each trading node updates the local password of the first user under this trading node to the update password.

[0075] In this example, the central node is a node without transaction functions, which is mainly used to add user accounts, delete user accounts, modify or reset the local passwords of users. In practical applications, the central node can be a calculator or a server. Exemplarily, the update requests sent by the client received by the central node can directly come from the client or be forwarded by other transaction nodes. Exemplarily, the local passwords of users under the central node are stored in the corresponding database, and the local passwords of users under each transaction node are stored in the corresponding database. After the central node successfully verifies the login password of the first user, password synchronization can be performed through database synchronization software, message queues, database triggers, etc. In the related art, the local passwords of users are centrally stored in an independent node, and user logins and user password modifications are performed through this independent node. The solution of this example takes into account the different daily demands for user password logins and user password modifications. The user password login demand is much greater than the user password modification demand. The user password login is dispersed among multiple transaction nodes, and the user password modification is centralized in the central node, thus reasonably utilizing node resources and improving the efficiency of user logins, and thereby improving the transaction efficiency. The solution of this example ensures the consistency and security of the local passwords of users in different nodes in the transaction system through a password update and synchronization mechanism, while enhancing the reliability and scalability of the system.

[0076] As another example, based on any example, the updated password sent by the client is the password encrypted based on the first encryption algorithm; before the central node updates the local password of the first user under this central node to the updated password, it further includes:

[0077] The central node encrypts the updated password based on the second encryption algorithm; wherein, the first encryption algorithm is different from the second encryption algorithm.

[0078] In practical applications, the first encryption algorithm can be a symmetric encryption algorithm to achieve fast data encryption on the client device. On the other hand, an asymmetric encryption algorithm can be used, with public key encryption and private key decryption, to be suitable for use in the central node where high security and key management are required. The solution of this example provides multi-level security protection at different stages through the use of different encryption algorithms.

[0079] Figure 6 It is a schematic flowchart of the transaction verification method provided by the embodiment of this application. The method of this embodiment is applied to the client, as Figure 6 shown, the transaction verification method includes:

[0080] Step 601: Send a login request to the trading nodes in the trading system. The trading system includes multiple trading nodes, and each trading node includes local passwords of multiple users. The login request includes the login password of the first user, where the first user is any one of the multiple users, and the multiple users include users belonging to the trading node and other trading nodes.

[0081] Step 602: Receive the verification result returned by the trading node. The verification result is obtained by the trading node based on verifying the login password of the first user by querying the local password of the first user obtained under this trading node.

[0082] In practical applications, the trading system can be a financial trading system such as an inter-bank payment and settlement system, a securities exchange, a foreign exchange trading platform, etc. The corresponding trading nodes can be bank servers, securities company servers, payment gateways. Optionally, the trading system can also be a blockchain network, and the corresponding trading nodes are blockchain nodes. Exemplarily, a trading node can be a general calculator, a server, or a dedicated hardware device, etc., which is responsible for functions such as processing user requests, verifying user identities, and executing trading instructions. For example, a trading node can be composed of at least one server, and multiple trading nodes may be distributed in different geographical locations to improve the reliability and response speed of the system. On the other hand, the client in this example can be an application program based on different operating systems such as a desktop application program or a mobile application program in practical applications. Optionally, the client can also be a web browser, or an API (Application Programming Interface) client connected to other systems.

[0083] Exemplarily, the login request received by the trading node from the client can come from a user. Specifically, the login request usually contains a user identifier (such as a username or user ID) and a login password, which are used to identify and verify the user identity in the trading node. In this example, the multiple users under different trading nodes are the same, and each trading node includes the local passwords of the users belonging to this trading node and other trading nodes. In an exemplary scenario, the login request received by the trading node can also be a login request from the client forwarded by other trading nodes to improve the flexibility of processing login requests.

[0084] Exemplarily, in addition to storing the local password of the user, the transaction node may also store other information of the users belonging to the transaction node for subsequent transactions. For example, the user's account information such as account balance, account status, account type, etc., or store the user's historical transaction records such as transaction time, transaction amount, counterparty, etc., or store the user's role in the system and its corresponding permission settings. In practical applications, each transaction node may include one or more databases to store the above data. Exemplarily, when storing the local password of the user, a secure hash algorithm (such as bcrypt, Argon2) is used to hash the password and store the hash value instead of the plaintext password to improve the security of the system. In this example, the transaction node verifies the login password of the first user based on the local password of the first user obtained by querying under this transaction node, that is, determines whether the local password of the first user is the same as the login password of the first user. Optionally, when the user updates the password, the local password of the user under the transaction node can also be updated regularly. Exemplarily, when the user updates the password, the update request propagates in the distributed database to ensure the consistency of all node data. Optionally, a centralized authentication and authorization service can also be used to manage the user's password and authentication information. In practical applications, the user password update request is sent to the centralized service, and this service is responsible for notifying the relevant transaction nodes to update.

[0085] The transaction verification method provided by the embodiments of this application includes: a transaction node in the transaction system receives a login request sent by the client, including the login password of the first user, verifies the login password of the first user based on the local password of the first user obtained by querying under this transaction node, and returns the verification result to the client. In the solution of this application, each transaction node includes the local passwords of multiple users, and each transaction node can independently respond to the login requests of users belonging to this node or other nodes, avoiding using a single transaction node to verify the user's login, thereby improving the reliability of financial transactions.

[0086] As another example, based on any example, the verification result includes the token of the first user and the transaction node information to which the first user belongs; Figure 7 It is a schematic flowchart of the transaction verification method provided by the embodiments of this application, as Figure 7 shown, the method further includes:

[0087] Step 701, according to the transaction node information to which the first user belongs, send a delegation request to the transaction node to which the first user belongs, and the delegation request includes the token of the first user;

[0088] Step 702: Receive the entrustment response returned by the trading node to which the first user belongs; the entrustment response is returned by the trading node to which the first user belongs after determining the login status of the first user based on the token of the first user.

[0089] Exemplarily, the entrustment request can be generated by the client based on the user's manual operation or a preset trading strategy. In practical applications, the entrustment request may include: request types such as buy, sell, query, etc., or trading parameters such as trading amount, asset type, quantity, etc. for detailed information, or client information such as the device information and IP address of the client for further security verification. Optionally, if the entrustment request is based on an established session, it may include a session ID or other relevant information. It should be noted that for the trading node, the first user is the user whose local password is stored under this trading node, and the second user is the user belonging to this trading node. Therefore, the first user and the second user are only used for distinction. In practical applications, the first user and the second user may be the same user or different users, which is not limited here. The solution of this example ensures the validity of the user identity and the security of trading operations by receiving and verifying the entrustment request sent by the client at the trading node; among them, using the token of the second user to confirm the login status can effectively prevent unauthorized access and operations, thereby improving the security and reliability of the trading process.

[0090] As another example, on the basis of any example, Figure 8 is a schematic flowchart of the trading verification method provided by the embodiment of the present application. As Figure 8 shown, the method further includes:

[0091] Step 801: Obtain the load status of each trading node;

[0092] Sending the login request to the trading node in the trading system in step 601 includes:

[0093] Step 802: Based on the load status of each trading node, send a login request to the trading node in the trading system.

[0094] Exemplarily, the load status of each trading node can be monitored in real time through a load balancer or a monitoring tool, including CPU usage, memory usage, network traffic, and the current number of connections, etc. In practical applications, after obtaining the load status of the trading node, a load threshold and a priority rule can be set, and its current processing capacity can be evaluated according to the load status of the node. Exemplarily, an intelligent allocation algorithm (such as round-robin, least connections, weighted random) can be used to determine which node to send the login request to. The solution of this example determines the trading node to which the login request is sent based on the load status of each trading node, which can optimize resource utilization and ensure the efficient operation and quick response of the trading system.

[0095] As another example, based on any example, the trading system further includes a central node, and the local passwords of multiple users are included under the central node; the method further includes:

[0096] Sending an update request to the central node; wherein, the update request includes the login password and the update password of the first user.

[0097] In this example, the central node is a node without trading functions, which is mainly used to add user accounts, delete user accounts, modify or reset the local passwords of users. In practical applications, the central node can be a calculator or a server. Exemplarily, the update request received by the central node from the client can directly come from the client or be forwarded by other trading nodes. Exemplarily, the local passwords of users under the central node are stored in the corresponding database, and the local passwords of users under each trading node are stored in the corresponding database. After the central node verifies the login password of the first user, password synchronization can be performed through database synchronization software, message queues, database triggers, etc. In the related art, the local passwords of users are centrally stored in an independent node, and user logins and user password modifications are performed through this independent node. The solution of this example takes into account the different daily demands for user password logins and user password modifications. The user password login is much greater than the user password modification. The user password login is dispersed among multiple trading nodes, and the user password modification is centralized in the central node, reasonably utilizing node resources and improving the efficiency of user logins, thereby improving the trading efficiency. The solution of this example ensures the consistency and security of the local passwords of users in different nodes in the trading system through the password update and synchronization mechanism, while enhancing the reliability and scalability of the system.

[0098] As another example, based on any example, before sending the update request to the central node, the method further includes: encrypting the update password based on the first encryption algorithm.

[0099] In practical applications, the first encryption algorithm can be a symmetric encryption algorithm to quickly encrypt data on the client device. On the other hand, an asymmetric encryption algorithm can be used, with public key encryption and private key decryption, to be suitable for use in the central node where high security and key management are required. The solution of this example provides multi-level security protection at different stages for the trading system by using different encryption algorithms.

[0100] The transaction verification method provided by the embodiments of this application includes: a transaction node in the transaction system receives a login request sent by a client, the login request includes the login password of a first user, verifies the login password of the first user based on the local password of the first user queried under this transaction node, and returns a verification result to the client. In the solution of this application, the local passwords of multiple users are included under each transaction node, and each transaction node can independently respond to the login requests of users belonging to this node or other nodes, avoiding using a single transaction node to verify user logins, thereby improving the reliability of financial transactions.

[0101] The embodiments of this application provide a transaction system, which includes multiple transaction nodes, and the local passwords of multiple users are included under each transaction node; among them,

[0102] The transaction node is used to receive a login request sent by a client, the login request includes the login password of a first user, the first user is any one of multiple users, and the multiple users include users belonging to this transaction node and other transaction nodes; the transaction node is further used to verify the login password of the first user based on the local password of the first user queried under this transaction node, and return a verification result to the client.

[0103] In one example, the transaction node information to which multiple users belong is further included under each transaction node; specifically, the transaction node is used to: if the verification is passed, query the transaction node information to which the first user belongs under this transaction node; return a verification result to the client, and the verification result includes the token of the first user and the transaction node information to which the first user belongs.

[0104] In one example, the transaction node is further used to: receive a delegation request sent by a client, the delegation request includes the token of a second user, and the second user is any one of the users belonging to this transaction node; determine the login status of the second user based on the token of the second user and return a delegation response.

[0105] In one example, the token includes: the identifier of the first user, the session number assigned by the transaction node to the first user, the timestamp, and the index of the first user in the transaction node.

[0106] In one example, the intervals of the session numbers assigned by different transaction nodes to the first user are different.

[0107] In one example, the transaction node is further used to: encrypt the token of the first user;

[0108] The trading node is specifically used for: decrypting the token of the second user and performing a legality verification: verifying the legality of at least one piece of data among the identifier, session number, timestamp, and index; if the decryption of the token of the second user is successful and the legality verification is successful, it is determined that the login status of the second user is passed.

[0109] In one example, the trading system further includes a central node, and the central node includes local passwords of multiple users; the central node is used for: receiving an update request sent by the client, where the update request includes the login password and the update password of the first user; based on the local password of the first user queried under this central node, verifying the login password of the first user, and if the verification passes, updating the local password of the first user under this central node to the update password, and synchronizing the update password to each trading node, so that each trading node updates the local password of the first user under this trading node to the update password.

[0110] In one example, the update password sent by the client is a password encrypted based on the first encryption algorithm; the central node is further used for: encrypting the update password based on the second encryption algorithm; where the first encryption algorithm is different from the second encryption algorithm.

[0111] The trading system provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effects are similar, and will not be elaborated here in this embodiment.

[0112] The embodiment of the present application provides a client, which is used for: sending a login request to a trading node in the trading system; where the trading system includes multiple trading nodes, and each trading node includes local passwords of multiple users; the login request includes the login password of the first user, and the first user is any one of the multiple users, and the multiple users include users belonging to the trading node and other trading nodes; receiving the verification result returned by the trading node; where the verification result is obtained by the trading node based on the local password of the first user queried under this trading node and verifying the login password of the first user.

[0113] In one example, the client is further used for: according to the trading node information to which the first user belongs, sending a delegation request to the trading node to which the first user belongs, where the delegation request includes the token of the first user; receiving the delegation response returned by the trading node to which the first user belongs; where the delegation response is returned by the trading node to which the first user belongs based on the token of the first user and determining the login status of the first user.

[0114] In one example, the client is further used for: obtaining the load status of each trading node; specifically, the client is used for: based on the load status of each trading node, sending a login request to a trading node in the trading system.

[0115] In one example, the client is further configured to: send an update request to the central node; wherein, the update request includes the login password and the updated password of the first user.

[0116] In one example, the client is further configured to: encrypt the updated password based on the first encryption algorithm.

[0117] The client provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, and will not be elaborated here in this embodiment.

[0118] Figure 9 It is an interaction schematic diagram of the trading system provided in the embodiment of the present application. As Figure 9 shown, after the client generates a login request based on the user's login operation, it selects a trading node based on the load status of the trading node, and sends the login request including the user's login password to the corresponding trading node. The corresponding trading node verifies the user's login password and returns a verification result including the user's token and the trading node information to which the user belongs to the client; after the client generates a delegation request based on the user's delegation operation, it determines the trading node information to which the user belongs, sends the delegation request including the user's token to the trading node, and the trading node to which the user belongs returns a delegation response.

[0119] Figure 10 It is an interaction schematic diagram of the trading system provided in the embodiment of the present application. As Figure 10 shown, the user can send an update request including the login password and the updated password to the central node on multiple clients such as a mobile application, a desktop application, and an API client. Among them, the trading node can also forward the update request of the mobile application. After the central node verifies the user's local password and synchronizes the updated password to the database of each trading node, the central node returns an update response to the client.

[0120] In the trading system provided in the embodiment of the present application, the trading node in the trading system receives the login request sent by the client, which includes the login password of the first user, verifies the login password of the first user based on the local password of the first user obtained by querying under this trading node, and returns a verification result to the client. In the solution of the present application, the local passwords of multiple users are included under each trading node, and each trading node can independently respond to the login requests of users belonging to this node or other nodes, avoiding using a single trading node to verify the user's login, thereby improving the reliability of financial transactions.

[0121] Figure 11 It is a structural schematic diagram of the electronic device provided in the embodiment of the present application. As Figure 11As shown in the figure, the electronic device provided in this embodiment includes: a processor 291, and the electronic device further includes a memory 292; it may also include a communication interface 293 and a bus 294. Among them, the processor 291, the memory 292, and the communication interface 293 can communicate with each other through the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can call the logical instructions in the memory 292 to execute the method in the above example.

[0122] In addition, when the logical instructions in the above-mentioned memory 292 are implemented in the form of software functional units and sold or used as an independent product, they can be stored in a computer-readable storage medium.

[0123] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as the program instructions / modules corresponding to the methods in the embodiments of the present application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, implements the methods in the above method examples.

[0124] The memory 292 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the terminal device. In addition, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0125] The embodiment of the present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the method in the above embodiment.

[0126] The embodiment of the present application also provides a computer-readable storage medium, in which computer-execution instructions are stored, and when the processor executes the computer-execution instructions, it implements the method in the above embodiment.

[0127] Finally, it should be noted that: After considering the specification and practicing the invention disclosed herein, those skilled in the art will easily think of other implementation schemes of the present invention. The present invention aims to cover any variations, uses, or adaptive changes of the present invention. These variations, uses, or adaptive changes follow the general principles of the present invention and include common general knowledge or conventional technical means in the technical field of the present invention that are not disclosed in the present invention. It is not limited to the exact structure described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present invention is only limited by the appended claims.

Claims

1. A transaction verification method, characterized in that: Applied to a trading system, the trading system includes a plurality of trading nodes, each of which includes a plurality of users' local passwords, the method includes: The transaction node receives a login request sent by a client, wherein the login request includes a login password of a first user, wherein the first user is any one of the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; The transaction node verifies the login password of the first user based on the local password of the first user obtained by querying under the transaction node, and returns the verification result to the client.

2. The method according to claim 1, characterized in that Each transaction node also includes the transaction node information to which the multiple users belong; and returns the verification result to the client, specifically including: If the verification is successful, the transaction node queries under the current transaction node to obtain the transaction node information to which the first user belongs; The transaction node returns a verification result to the client, where the verification result includes the token of the first user and the transaction node information to which the first user belongs.

3. The method according to claim 2, characterized in that The method further comprises: The transaction node receives a delegation request sent by a client, where the delegation request includes a token of a second user, where the second user is any user belonging to the transaction node; The transaction node determines the login status of the second user based on the token of the second user and returns a delegation response.

4. The method according to claim 3, characterized in that: The token includes: an identifier of the first user, a session number assigned by the transaction node to the first user, a timestamp, and an index of the first user in the transaction node.

5. The method according to claim 4, characterized in that Different transaction nodes allocate different intervals of session numbers to the first user.

6. The method according to claim 4, characterized in that The method further comprises: The transaction node encrypts the token of the first user; The transaction node determines the login status of the second user based on the token of the second user, including: The transaction node decrypts the token of the second user and performs legitimacy verification: verifying the legitimacy of at least one item of data in the identifier, the session number, the timestamp, and the index; If the transaction node successfully decrypts the token of the second user and the legitimacy verification is successful, the login status of the second user is determined to be passed.

7. The method according to any one of claims 1 to 6, characterized in that The transaction system further includes a central node, and the central node includes local passwords of multiple users; the method further includes: The central node receives an update request sent by the client, wherein the update request includes a login password and an update password of the first user; The central node verifies the login password of the first user based on the local password of the first user obtained by querying under the central node. If the verification passes, the local password of the first user under the central node is updated to the updated password, and the updated password is synchronized to each transaction node, so that each transaction node updates the local password of the first user under the transaction node to the updated password.

8. The method according to claim 7, characterized in that The updated password sent by the client is a password encrypted based on a first encryption algorithm; before the central node updates the local password of the first user under the central node to the updated password, the method further includes: The central node encrypts the update password based on a second encryption algorithm; wherein the first encryption algorithm is different from the second encryption algorithm.

9. A transaction verification method, characterized in that: Applied to a client, the method comprises: Sending a login request to a transaction node in a transaction system; wherein the transaction system includes multiple transaction nodes, each transaction node includes local passwords of multiple users; the login request includes a login password of a first user, the first user is any user among the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; Receive a verification result returned by the transaction node; wherein the verification result is obtained by the transaction node after verifying the login password of the first user based on the local password of the first user obtained by querying under the transaction node.

10. The method according to claim 9, characterized in that The verification result includes the token of the first user and the transaction node information to which the first user belongs; the method further includes: Sending a delegation request to the transaction node to which the first user belongs according to the transaction node information to which the first user belongs, wherein the delegation request includes a token of the first user; A delegation response is received from the transaction node to which the first user belongs; wherein the delegation response is returned by the transaction node to which the first user belongs after determining the login status of the first user based on the token of the first user.

11. The method according to claim 9, characterized in that The method further comprises: Get the load status of each transaction node; Send a login request to the transaction node in the transaction system, including: Based on the load status of each transaction node, a login request is sent to the transaction nodes in the transaction system.

12. The method according to any one of claims 9 to 11, characterized in that The transaction system further includes a central node, and the central node includes local passwords of multiple users; the method further includes: An update request is sent to the central node; wherein the update request includes the login password and update password of the first user.

13. The method according to claim 12, characterized in that Before sending the update request to the central node, the method further includes: The update password is encrypted based on a first encryption algorithm.

14. A trading system, characterized in that: The trading system includes multiple trading nodes, each of which includes local passwords of multiple users; The transaction node is configured to receive a login request sent by a client, wherein the login request includes a login password of a first user, wherein the first user is any one of the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; The transaction node is further configured to verify the login password of the first user based on the local password of the first user obtained by querying under the transaction node, and return a verification result to the client.

15. A client, characterized in that: The client is used to: Sending a login request to a transaction node in a transaction system; wherein the transaction system includes multiple transaction nodes, each transaction node includes local passwords of multiple users; the login request includes a login password of a first user, the first user is any user among the multiple users, and the multiple users include users belonging to the transaction node and other transaction nodes; Receive a verification result returned by the transaction node; wherein the verification result is obtained by the transaction node after verifying the login password of the first user based on the local password of the first user obtained by querying under the transaction node.

16. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the processor executes the method according to any one of claims 1-8 or any one of claims 9-13.

17. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method according to any one of claims 1 to 8 or any one of claims 9 to 13.

18. A computer program product, comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 8 or any one of claims 9 to 13.

Images