CN107547512B - User authentication method and device in multi-level cloud platform - Google Patents
User authentication method and device in multi-level cloud platform Download PDFInfo
- Publication number
- CN107547512B CN107547512B CN201710574685.4A CN201710574685A CN107547512B CN 107547512 B CN107547512 B CN 107547512B CN 201710574685 A CN201710574685 A CN 201710574685A CN 107547512 B CN107547512 B CN 107547512B
- Authority
- CN
- China
- Prior art keywords
- user
- cloud platform
- database
- user data
- version
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a user authentication method and a user authentication device in a multilevel cloud platform, wherein the method comprises the following steps: maintaining a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-stage cloud platform; when a user authentication request sent to the cloud platform is received, comparing user data in the user authentication request with user data of a corresponding user in a local user database; and if the user data with the consistent version exists in the local user database and the user authentication data in the local user database is the latest version, returning an authentication success message. And otherwise, sending a new version user data acquisition request including the user data to the upper-level cloud platform, and when receiving the latest version user data of the corresponding user returned by the upper-level cloud platform, storing the latest version user data into the local user database and re-authenticating.
Description
Technical Field
The invention relates to the technical field of computer networks, in particular to a user authentication method and device in a multilevel cloud platform.
Background
With the advent of the cloud computing era, large enterprises, government departments and the like migrate more and more businesses to private cloud platforms. As business grows, the independent private cloud platform exposes some problems. For example, the business reliability problem is that all businesses are concentrated in one private cloud platform, and when the private cloud platform encounters a serious disaster, all businesses are affected.
For this reason, solutions for multi-level cloud platforms have emerged. The multilevel cloud platform is that relatively independent private cloud platforms are respectively established in various places, and the management layer network among the private cloud platforms can be reached. The private cloud platform can effectively utilize existing resources in various places, and service data can be mutually backed up in a plurality of remote private cloud platforms, so that when one private cloud platform goes wrong, the service can be unaffected or quickly restored in different places.
The multi-level cloud platform is generally a tree-like organization structure, and the root node is generally called a top-level private cloud platform. For any node (private cloud platform) therein, the subordinate node can be called as a subordinate cloud platform, and similarly, the superior node can be called as a superior cloud platform. Each private cloud platform in the multi-level cloud platform is a relatively independent cloud platform, and different cluster structures and database modes are used for responding to respective internal service requirements. In management, all resources in the multilevel cloud platform can be managed by using a set of interface entries of the cloud platform without switching a management interface by a user. The multi-level cloud platform provides an effective entrance for centralized management of a plurality of private cloud platform resources, provides uniform use experience, and enables a user to seamlessly switch among a plurality of relatively independent private cloud platforms, thereby being more beneficial to integration of resources in the private cloud platforms.
The user authentication function is used as an entry function of the multi-level cloud platform management, and the authentication functions of the private cloud platforms need to be coordinated, so that a user can log in any cloud platform in the multi-level cloud platform, all resources in the multi-level cloud platform can be managed, and non-differentiated experience is achieved. In the prior art, the method for implementing the authentication function of the multi-level cloud platform generally includes: shared user authentication service implementation. That is, when the private cloud platforms in the multi-level cloud platform are connected to each other, the authentication service in the private cloud platform is deactivated, but the authentication service of the root private cloud platform is used as the authentication service of the root private cloud platform, and a system architecture using this method is shown in fig. 1. As shown in fig. 1, when the cloud platforms at different levels are connected to each other, the authentication service of the non-top cloud platform is in a deactivated state (light gray), and the business service of the cloud platforms at different levels forwards the authentication request to the authentication service of the top cloud platform (dark gray). When a user authentication request occurs, the authentication request is directly sent to the authentication service of the top-level private cloud platform, and corresponding data is returned after the authentication is passed, and the authentication process is shown in fig. 2.
This method has the following problems:
1) the performance problem is more obvious: all authentication requests need to use a wide area network between private cloud platforms, generally, the network has poor quality relative to the internal network of the private cloud platforms, and the influence probability is high, so that frequent use of the network link causes unstable connection, and the authentication performance is influenced;
2) single point problem: when the top-level private cloud platform fails, all nodes (private cloud platforms) of the multi-level cloud platform cannot be used;
3) the service coupling is high: due to the fact that the authentication service of the top-level cloud platform is used, all services in the multi-level cloud platform need to be modified and point to the authentication service of the top-level cloud platform, modification workload is large, and maintenance is not easy.
Disclosure of Invention
In order to at least partially solve the above problem, the present invention provides a user authentication method in a multi-level cloud platform, which is applied to each cloud platform in the multi-level cloud platform, and includes:
maintaining a local user database in the cloud platform, and keeping the local user database consistent with user databases in other cloud platforms in the multi-stage cloud platform; user data of each user is stored in the local user database;
when a user authentication request sent to the cloud platform is received, comparing user data in the user authentication request with user data of a corresponding user in a local user database;
if the user data with the consistent version exists in the local user database, judging whether the user authentication data in the user data with the consistent version is the same as the user authentication data in the user data of the latest version of the user in the local user database, and if so, returning an authentication success message;
if the user data with the consistent version does not exist in the local user database, sending a new version user data acquisition request including the user data in the user authentication request to an upper-level cloud platform;
and when receiving the latest version of user data of the corresponding user returned by the upper-level cloud platform, storing the latest version of user data into a local user database, and re-authenticating the user authentication request.
Optionally, the method further comprises:
when a new version user data acquisition request sent to the cloud platform by a next-level cloud platform is received, comparing user data in the new version user data acquisition request with user data of corresponding users in a local user database;
if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the next-level cloud platform;
if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform exists, the new-version user data acquisition request is forwarded to the upper-level cloud platform, and when the latest version of user data of the corresponding user returned by the upper-level cloud platform is received, the latest version of user data is stored in the local database, and the latest version of user data is sent to the lower-level cloud platform;
and if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform does not exist, generating a reverse new-version user data acquisition request and sending the reverse new-version user data acquisition request to all the lower-level cloud platforms to acquire the user data of the latest version.
Optionally, the method further comprises:
when a reverse new version user data acquisition request sent to a local cloud platform by a previous-stage cloud platform is received, comparing user data in the reverse new version user data acquisition request with user data of corresponding users in a local user database;
if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the upper-level cloud platform;
if the user data with the consistent version does not exist in the local user database and the next-level cloud platform exists, the reverse new-version user data acquisition request is forwarded to all the next-level cloud platforms, and when the latest version of user data of the corresponding user returned by the next-level cloud platform is received, the latest version of user data is stored in the local database and the latest version of user data is sent to the previous-level cloud platform;
and if the user data with consistent versions does not exist in the local user database and the next-level cloud platform does not exist, no processing is performed.
Optionally, the maintaining a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-level cloud platform, includes:
when receiving new user data from a user, which is sent to the cloud platform, giving a new version identifier to the new user data, and adding the new user data into a user data set of a corresponding user in a local user database;
and sending the user data set of the corresponding user in the local user database to the upper-level cloud platform and the lower-level cloud platform as synchronous data of the corresponding user.
Optionally, the maintaining a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-level cloud platform, includes:
when receiving new user data from a user, which is sent to the cloud platform, giving a new version identifier to the new user data, and adding the new user data into a user data set of a corresponding user in a local user database;
and sending the user data set of the corresponding user in the local user database to an upper-level cloud platform and a lower-level cloud platform as synchronous data of the corresponding user.
Optionally, the maintaining a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-level cloud platform, further includes:
when receiving the synchronous data sent by the upper-level cloud platform/the lower-level cloud platform to a user of the cloud platform, comparing the synchronous data with a user data set of the corresponding user in the local user database;
if the user data set of the corresponding user in the local user database is the subset of the received synchronous data, replacing the user data set of the corresponding user in the local user database with the synchronous data, and sending the synchronous data to an upper-level cloud platform and a lower-level cloud platform;
if the user data set of the corresponding user in the local user database has data inconsistent with the synchronous data, integrating the user data set of the corresponding user in the local user database with the synchronous data to obtain a new user data set of the corresponding user, replacing the user data set of the corresponding user in the local user database with the new user data set, and sending the new user data set to a target cloud platform as the synchronous data of the corresponding user, wherein when the received synchronous data is sent by a previous-level cloud platform, the target cloud platform is a next-level cloud platform, and when the received synchronous data is sent by the next-level cloud platform, the target cloud platform is the previous-level cloud platform;
and if the user data set of the corresponding user in the local user database is completely consistent with the synchronous data, no processing is performed.
Optionally, the maintaining a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-level cloud platform, further includes:
maintaining the version identification of the local user database according to the user data set of each user in the local user database, and correspondingly modifying the version identification of the local user database when the user data in the local user database is changed;
after a preset time interval is reached, requesting a database version identification of a user database of an upper-level cloud platform from the upper-level cloud platform, and requesting a database version identification of a user database of a lower-level cloud platform from the lower-level cloud platform; the preset time interval corresponding to each cloud platform is randomly generated;
respectively comparing the received database version identification of the user database of the previous-stage cloud platform and the received database version identification of the user database of the next-stage cloud platform with the database version identification of the local user database;
if the database version identification of the local user database is consistent with the received database version identification, no processing is performed;
if the database version identification of the local user database is inconsistent with any received database version identification, determining the synchronous data of at least one user according to the two inconsistent database version identifications;
and sending the synchronous data of the user to an upper-level cloud platform and a lower-level cloud platform.
According to another aspect of the present invention, there is provided a user authentication apparatus in a multi-level cloud platform, which is applied to each cloud platform in the multi-level cloud platform, including:
the system comprises a user data maintenance unit, a data processing unit and a data processing unit, wherein the user data maintenance unit is used for maintaining a local user database in a local cloud platform so as to keep the local user database consistent with user databases in other cloud platforms in the multi-level cloud platform; the local user database stores user data of different versions of each user;
the verification unit is used for comparing user data in the user authentication request with user data of corresponding users in a local user database when the user authentication request sent to the cloud platform is received; if the user data with the consistent version exists in the local user database, judging whether the user authentication data in the user data with the consistent version is the same as the user authentication data in the user data of the latest version of the user in the local user database, and if so, returning an authentication success message;
the verification unit is further configured to send a new version user data acquisition request including the user data in the user authentication request to an upper-level cloud platform if the user data with the consistent version does not exist in the local user database;
the user data maintenance unit is also used for storing the latest version of user data in a local user database when receiving the latest version of user data of a corresponding user returned by the upper-level cloud platform;
the verification unit is further configured to re-authenticate the user authentication request.
Optionally, the verification unit is further configured to compare user data in a new version user data acquisition request with user data of a corresponding user in a local user database when receiving the new version user data acquisition request sent by a next-level cloud platform to the cloud platform; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the next-level cloud platform; if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform exists, forwarding the new-version user data acquisition request to the upper-level cloud platform;
the user data maintenance unit is used for storing the latest version of user data in a local database and sending the latest version of user data to a next-level cloud platform when receiving the latest version of user data of a corresponding user returned by the previous-level cloud platform;
the verification unit is further configured to generate a reverse new version user data acquisition request and send the reverse new version user data acquisition request to all next-level cloud platforms to acquire the latest version user data if the user data with the consistent version does not exist in the local user database and the previous-level cloud platform does not exist.
Optionally, the verification unit is further configured to compare user data in the reverse new version user data acquisition request with user data of a corresponding user in a local user database when receiving the reverse new version user data acquisition request sent by the previous cloud platform to the local cloud platform; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the upper-level cloud platform; if the user data with the consistent version does not exist in the local user database and the next-level cloud platform exists, forwarding the reverse new-version user data acquisition request to all the next-level cloud platforms; if the user data with the consistent version does not exist in the local user database and the next-level cloud platform does not exist, no processing is performed;
the user data maintenance unit is further configured to, when receiving the latest version of user data of a corresponding user returned by the next-stage cloud platform, store the latest version of user data in the local database, and send the latest version of user data to the previous-stage cloud platform.
Optionally, the user data maintenance unit is configured to, when receiving new user data sent to the local cloud platform from a user, assign a new version identifier to the new user data, and add the new user data to a user data set of a corresponding user in the local user database; and sending the user data set of the corresponding user in the local user database to an upper-level cloud platform and a lower-level cloud platform as synchronous data of the corresponding user.
Optionally, the user data maintenance unit is further configured to compare the received synchronization data of the user sent to the cloud platform by the previous cloud platform/the next cloud platform with a user data set of a corresponding user in the local user database; if the user data set of the corresponding user in the local user database is the subset of the received synchronous data, replacing the user data set of the corresponding user in the local user database with the synchronous data, and sending the synchronous data to a target cloud platform, wherein when the received synchronous data is sent by an upper-level cloud platform, the target cloud platform is a lower-level cloud platform, and when the received synchronous data is sent by the lower-level cloud platform, the target cloud platform is the upper-level cloud platform; if the user data set of the corresponding user in the local user database has data inconsistent with the synchronous data, integrating the user data set of the corresponding user in the local user database with the synchronous data to obtain a new user data set of the corresponding user, replacing the user data set of the corresponding user in the local user database with the new user data set, and sending the new user data set to an upper-level cloud platform and a lower-level cloud platform as the synchronous data of the corresponding user; and if the user data set of the corresponding user in the local user database is completely consistent with the synchronous data, no processing is performed.
Optionally, the user data maintenance unit is further configured to maintain the version identifier of the local user database according to a user data set of each user in the local user database, and modify the version identifier of the local user database when the user data in the local user database changes; after a preset time interval is reached, requesting a database version identification of a user database of an upper-level cloud platform from the upper-level cloud platform, and requesting a database version identification of a user database of a lower-level cloud platform from the lower-level cloud platform; the preset time interval corresponding to each cloud platform is randomly generated; respectively comparing the received database version identification of the user database of the previous-stage cloud platform and the received database version identification of the user database of the next-stage cloud platform with the database version identification of the local user database; if the database version identification of the local user database is consistent with the received database version identification, no processing is performed; if the database version identification of the local user database is inconsistent with any received database version identification, determining the synchronous data of at least one user according to the two inconsistent database version identifications; and sending the synchronous data of the user to an upper-level cloud platform and a lower-level cloud platform.
Therefore, according to the technical scheme of the invention, a user database which can keep consistency with other cloud platforms is maintained in the cloud platform to store the user data of each user, so that when a user authentication request sent to the cloud platform is received, the user data in the user authentication request is compared with the user data of the corresponding user in the local user database, if the versions are consistent and the user authentication data is latest, the authentication is successful, and if the versions are inconsistent, the user data of the latest version is obtained for re-authentication. According to the technical scheme, the authentication functions in the cloud platforms can be relatively independent, the consistency of data among the cloud platforms can be guaranteed, the coupling of authentication services in the cloud platforms is greatly reduced, and the development of the authentication services in the cloud platforms is facilitated based on internal system architectures of the cloud platforms; and the load of the top-level cloud platform is reduced, network communication is reduced, and the authentication efficiency is improved.
Drawings
FIG. 1 is a simplified diagram of a system architecture of a multi-level cloud platform with an authentication service deployed in the prior art;
FIG. 2 is a flow diagram illustrating user authentication in a multi-level cloud platform according to the prior art;
FIG. 3 is a system architecture diagram of a multi-level cloud platform with authentication services deployed in an embodiment of the present invention;
FIG. 4 is a flowchart illustrating a method for user authentication in a multi-level cloud platform according to an embodiment of the present invention;
FIG. 5 is a flow diagram illustrating another method of user authentication in a multi-level cloud platform, according to one embodiment of the invention;
FIG. 6 illustrates a flow diagram of user data synchronization in a multi-level cloud platform, according to one embodiment of the present invention;
fig. 7 is a schematic structural diagram of a user authentication device in a multi-level cloud platform according to an embodiment of the present invention;
fig. 8 is a diagram illustrating a network device hardware configuration according to an embodiment of the present invention.
Detailed Description
In order to solve the technical problems proposed in the background art, the inventors of the present application think that relatively independent authentication services are respectively deployed on each level of cloud platform, so that when a user accesses a certain cloud platform, the user authentication can be completed through the authentication services deployed in the cloud platform. Fig. 3 shows a system architecture schematic diagram of a multi-level cloud platform with an authentication service deployed in an embodiment of the present invention, and as can be seen from comparing fig. 1 and fig. 3, in fig. 1, when the private cloud platforms are connected to each other, the authentication service in the non-top-level private cloud platform is in a disabled state, and the business service directly sends a request to the authentication service in the top-level cloud platform. As can be seen from fig. 3, in the embodiment of the present invention, when the private cloud platforms are connected to each other, the service in the cloud platform still sends a request to the authentication service in the cloud platform for authentication.
However, this method has a new problem: how to ensure consistency of user data. For example, if a user registers on a certain cloud platform, how to enable other cloud platforms to obtain user data of the user is a problem to be solved, because the user is likely to need to log in on other cloud platforms. In response to this problem, as shown in fig. 3, data communication is possible between authentication services, and this design enables data synchronization.
Therefore, the application example discloses a user authentication method and device in a multilevel cloud platform, so as to solve the problems that the authentication service performance of the multilevel cloud platform is not high, the coupling degree is high and the like in the prior art. In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Fig. 4 is a flowchart illustrating a user authentication method in a multi-level cloud platform, which is applied to each cloud platform in the multi-level cloud platform, and can be specifically executed by a deployed authentication service according to an embodiment of the present invention. As shown in fig. 4, the method includes:
step S410, maintaining a local user database in the cloud platform, and keeping the local user database consistent with user databases in other cloud platforms in the multi-level cloud platform; the local subscriber database stores subscriber data of each subscriber. User data is maintained by versions, for example, when a user is newly created, items of user data (such as name, age, password) of the user are identified by the original version after obtaining the original data, and when any item of user data is modified, the version of the user data is changed, so that a plurality of versions of the user data may exist for one user. In this embodiment, all versions of user data may be saved for authentication and data backtracking.
Different from the authentication method of the conventional service, in this embodiment, a Token (Token) method may be considered to be used for user authentication, that is, after a user successfully logs in a cloud platform through a client for the first time, the Token of an initial version issued by an authentication service in the cloud platform is received and stored in the client, and only the Token needs to be sent to the authentication service when logging in next time. When the user updates the user data, login again will obtain a new version of Token. In this embodiment, the Token may be a carrier containing user data, and specifically may be user data encrypted by a private key. It should be noted that the "local user database" is not a database of "local users", but a user database maintained locally (i.e., a device running the cloud platform).
Step S420, when receiving the user authentication request sent to the cloud platform, comparing the user data in the user authentication request with the user data of the corresponding user in the local user database. For example, when the Token mode is adopted for user authentication, the user data may be analyzed from Token first.
For example, after logging in the cloud platform once, the user modifies the user data once again, so that the local user database of the cloud platform stores two versions of user data, namely 1.0 and 1.1. When a user uses only one client, it should be Token containing the latest version (i.e. version 1.1) of user data that is stored on the client. When the user logs in the cloud platform again, a user authentication request (Token in this example) containing the user data of version 1.1 is sent to the business service, the business service forwards the user authentication request to the authentication service, the authentication service compares the user data of the user in the local user database, because the user data of version 1.1 is stored in the local user database, whether the user authentication data in the user data of the consistent version is the same as the user authentication data in the user data of the latest version of the user in the local user database is judged, obviously, because the version of the user data is the latest version, the user authentication data is necessarily the same, the authentication is successful, namely step S430, if the user data of the consistent version exists in the local user database, whether the user authentication data in the user data of the consistent version is the same as the user authentication data of the latest version of the user in the local user database is judged, if yes, returning an authentication success message.
If a user uses multiple clients, it may happen that old versions of user data are saved on some clients. Then, via step 430, it is found that consistent version of the user data exists in the local user database, but further determination is needed since the user data is historical data. If the user modifies only some less important personal information and does not modify user authentication data such as login password when modifying the user data last time, the user data may be verified, and preferably, the user data of the latest version may be re-issued to the user for use, for example, the user is prompted to ask for re-acquisition if Token expires. If the user modifies the password last time, the user authentication data in the user data with the same version at this time is not the latest, and the authentication fails at this time.
In specific implementation, the version identifier of the user data may also be analyzed and compared with the version identifiers of the user data stored in the local user database. The authenticated user in the embodiment is a user who can log in the multi-level cloud platform, or a user who only logs in the internal service on the cloud platform, and for the second type of user, the user data does not need to be synchronized into user databases in other cloud platforms. The user database in this embodiment is not limited to a narrow database, and may be stored in a file or a collection in a predetermined format.
Although the local user database is consistent with the user databases in other cloud platforms in the multi-level cloud platform, it may still occur that, when the user sends the user authentication request through the client, the local user database does not yet have the version of the user data included in the user authentication request due to reasons such as poor network communication when the user data is synchronized, and then step S440 is executed. If the user data with the consistent version does not exist in the local user database, sending a new version user data acquisition request including the user data in the user authentication request to the upper-level cloud platform; and when receiving the latest version of the user data of the corresponding user returned by the upper-level cloud platform, storing the latest version of the user data into a local user database, and re-authenticating the user authentication request.
As introduced in the background art, since the multi-level cloud platform is of a tree structure, a method with higher efficiency is also considered when synchronizing the user data, and therefore, the possibility that new version user data exists in a parent node (i.e., an upper-level cloud platform) is higher, in this embodiment, in order to improve the authentication efficiency, it is not considered to send a new version user data acquisition request to a lower-level cloud platform (there may be a plurality of lower-level cloud platforms), but to send a new version user data acquisition request to an upper-level cloud platform.
It can be seen that, in the method shown in fig. 4, a user database capable of maintaining consistency with other cloud platforms is maintained in the cloud platform to store user data of different versions of each user, so that when a user authentication request sent to the cloud platform is received, the user data in the user authentication request is compared with the user data of a corresponding user in the local user database, if the versions are consistent and the user authentication data is latest, the authentication is successful, and if the versions are not consistent, the user data of the latest version is acquired and re-authenticated. According to the technical scheme, the authentication functions in the cloud platforms can be relatively independent, the consistency of data among the cloud platforms can be guaranteed, the coupling of authentication services in the cloud platforms is greatly reduced, and the development of the authentication services in the cloud platforms is facilitated based on internal system architectures of the cloud platforms; and the load of the top-level cloud platform is reduced, network communication is reduced, and the authentication efficiency is improved.
Then, for the cloud platform, if a new version user data acquisition request sent by the next-level cloud platform is received, how should the new version user data acquisition request be processed? In an embodiment of the present invention, the method further includes: when a new version user data acquisition request sent to the cloud platform by a next-stage cloud platform is received, comparing user data in the new version user data acquisition request with user data of corresponding users in a local user database; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the next-level cloud platform; if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform exists, the new-version user data acquisition request is forwarded to the upper-level cloud platform, and when the latest version of user data of the corresponding user returned by the upper-level cloud platform is received, the latest version of user data is stored in the local database, and the latest version of user data is sent to the lower-level cloud platform; and if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform does not exist, generating a reverse new-version user data acquisition request and sending the reverse new-version user data acquisition request to all the lower-level cloud platforms to acquire the user data of the latest version.
That is, it is divided into a plurality of cases to be handled. When the user data with the consistent user data version in the new version user data acquisition request exists in the local user database of the cloud platform, the situation is simplest, and the user data with the consistent version is directly used as the user data of the latest version of the user and sent to the next-level cloud platform. And if the local user database does not have the user data with the consistent user data version in the new-version user data acquisition request, forwarding the new-version user data acquisition request to the previous-level cloud platform until the local user database of the previous-level cloud platform has the user data with the consistent version, and issuing the user data step by step. The authentication flow in this manner can refer to fig. 5.
One complication is that up to the top level cloud platform, no consistent version of user data is found in the local user databases of the cloud platforms. The reasons for this may be: after a user modifies user data on a certain cloud platform, the cloud platform generates new versions of the user data, but the synchronization is not successful. Then it is also only chosen to traverse the tree starting from the root node, since the latest version of the user data may be present in any non-traversed node of the tree structure. At this time, unlike the request sent by the next-stage cloud platform to the previous-stage cloud platform, the request sent by the previous-stage cloud platform to all the next-stage cloud platforms of the cloud platform may be executed concurrently. Since the request is different from the new version user data obtaining request in the direction, it is referred to as a reverse new version user data obtaining request in this embodiment. Specifically, the following embodiments may be referred to as a processing method when a data acquisition request of a reverse new version is received:
in one embodiment of the invention, the method further comprises: when a reverse new-version user data acquisition request sent to the cloud platform by the previous-stage cloud platform is received, comparing user data in the reverse new-version user data acquisition request with user data of corresponding users in a local user database; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the upper-level cloud platform; if the user data with the consistent version does not exist in the local user database and the next-level cloud platform exists, the reverse new-version user data acquisition request is forwarded to all the next-level cloud platforms, and when the latest version of user data of the corresponding user returned by the next-level cloud platform is received, the latest version of user data is stored in the local database and the latest version of user data is sent to the previous-level cloud platform; and if the user data with consistent versions does not exist in the local user database and the next-level cloud platform does not exist, no processing is performed.
Although the synchronization of the user data is mentioned in the above embodiments, no specific example has been given yet, and in an embodiment of the present invention, the maintaining the local user database in the present cloud platform, so that the local user database is consistent with the user databases in other cloud platforms in the multi-level cloud platform, includes: when receiving new user data from a user, which is sent to the cloud platform, giving a new version identifier to the new user data, and adding the new user data into a user data set of a corresponding user in a local user database; and sending the user data set of the corresponding user in the local user database to the upper-level cloud platform and the lower-level cloud platform as the synchronous data of the corresponding user.
That is, for each user, the multiple versions of the user data have version identifiers, and when the user modifies the user data, new authentication data of the user is obtained, and a new version identifier (e.g., version number) is generated. User data of a user is stored in a user data set and is synchronized when the user data is newly added, that is, in response to the newly added passive synchronization of the user data.
The above "passive synchronization" is for the authentication service of the present cloud platform, and for the upper-level cloud platform and the lower-level cloud platform of the cloud platform, this synchronization is an active synchronization initiated by the cloud platform sending the synchronization data. When a certain cloud platform initiates such synchronization, the authentication service in the upper-level cloud platform and the authentication service in the lower-level cloud platform need to use the user synchronization data to determine what operation should be executed by the authentication service. Therefore, in an embodiment of the present invention, in the method, maintaining the local user database in the cloud platform, so that the local user database is consistent with the user databases in other cloud platforms in the multi-level cloud platform, further includes: when receiving the synchronous data sent by the upper-level cloud platform/the lower-level cloud platform to a user of the cloud platform, comparing the synchronous data with a user data set of the corresponding user in the local user database; if the user data set of the corresponding user in the local user database is the subset of the received synchronous data, replacing the user data set of the corresponding user in the local user database with the synchronous data, and sending the synchronous data to a target cloud platform, wherein when the received synchronous data is sent by an upper-level cloud platform, the target cloud platform is a lower-level cloud platform, and when the received synchronous data is sent by the lower-level cloud platform, the target cloud platform is the upper-level cloud platform; if the user data set of the corresponding user in the local user database has data inconsistent with the synchronous data, integrating the user data set and the synchronous data of the corresponding user in the local user database to obtain a new user data set of the corresponding user, replacing the user data set of the corresponding user in the local user database with the new user data set, and sending the new user data set to an upper-level cloud platform and a lower-level cloud platform as the synchronous data of the corresponding user; and if the user data set of the corresponding user in the local user database is completely consistent with the synchronous data, no processing is performed.
A flow chart of this approach can be seen in fig. 6. In a specific embodiment, when a user updates (adds, modifies, or deletes) user data, if it is an old user, at least one version of user data exists in the user database, and each version of user data corresponds to user data entered at a certain time. For example, the user data corresponding to the user data version 1.0 of user a is: [ Name: Zhangsan; age; and 22], the user adds new user data 'Sex: Male' this time, and the user data corresponding to the user data 1.1 version of the user A is as follows: [ Name: Zhangsan; age; 22; sex: Male ]. It is also possible to record in the user data detailed information of each operation performed by the user on the user data, such as which item was modified, the time of the operation, and the like. Then, after the user a modifies the user data, step 6a is triggered to generate new user data, the authentication service of the cloud platform of this level acquires the user data a (version 1.0) of the user in the local user database according to step 6B, and step 6c adds the user data into the local user database to acquire new user data B (version 1.1), and adds the user data B into the user data set of the user. And then sending the 1.0 version and the 1.1 version of the user data of the user A, namely the user data set of the user A, as the synchronous data of the user to an upper-level cloud platform and a lower-level cloud platform, namely triggering step 6d, and sending the user data A, B to the upper-level cloud platform and the lower-level cloud platform. Taking the above-level cloud platform as an example, after receiving the user data set of the user a, the authentication service of the cloud platform triggers step 6e to obtain the user data of the user in the local user database, and then compares the user data with the user data set of the user a in the local user database; there are many cases when the user data set of user a in the local user database is a subset of the received synchronization data (e.g. only 1.0 version of the user data), the received synchronization data is substituted for the user data set of the corresponding user in the local user database (trigger step 6g), and the synchronization data is sent to the upper cloud platform (trigger step 6 h). And after receiving the data, the upper-level cloud platform continues to perform similar processing. In some cases, if the synchronization data received by a certain level of cloud platform is completely consistent with the user data in the user data set of user a in the local user database, no processing is performed (triggering step 6 f).
One complicated situation is that if the authentication service of the previous cloud platform of the original cloud platform sending the synchronization data determines that data inconsistent with the synchronization data exists in the user data set a of the user in the local user database (for example, there are user data of version 1.0 and version 1.05, and the user data of version 1.05 is [ Name: ZhangSan; ID; 20000; Sex: Male ]), the latest version of user data is obtained by merging the user data set of the corresponding user and the synchronization data in the local user database according to the operation time of the user data, i.e., the new user data set of the user a (including the user data of version 1.0, 1.05, 1.1, 1.15) is obtained by integrating the user data set of the corresponding user and the synchronization data in the local user database, wherein the user data of version 1.15 includes all the user data [ Name: ZhangSan; ID; eage 22; Sex: 20000, for all the user data recorded in the user data of version 1.0, 1.05, 1.1, 1, etc. Of course, relevant operation information, not shown, may also be included), the user data set of the corresponding user in the local user database is replaced with the new user data set (triggering step 6i), and the new user data set is sent to the upper-level cloud platform and the lower-level cloud platform as the synchronization data of the corresponding user (triggering step 6 j).
We will find that the user data sets in the user databases of the respective cloud platforms should be completely consistent, at least that this more complex situation above should not occur-but in fact this is completely possible. This is because the cloud platforms are not necessarily able to maintain the connection with each other without interruption, which results in that after a user updates user data, the synchronization operation as described above should be performed, but since a certain cloud platform is not connected, the cloud platform cannot obtain the updated data. Although the cloud platform can complete synchronization during authentication by the method described in the above embodiment when the user logs in the cloud platform with new user data, the user experience is obviously reduced. Therefore, in an embodiment of the present invention, in the method, maintaining the local user database in the cloud platform, so that the local user database is consistent with the user databases in other cloud platforms in the multi-level cloud platform, further includes: maintaining the version identification of the local user database according to the user data set of each user in the local user database, and correspondingly modifying the version identification of the local user database when the user data in the local user database is changed; after the preset time interval is reached, requesting a database version identification of a user database of an upper-level cloud platform from the upper-level cloud platform, and requesting a database version identification of a user database of a lower-level cloud platform from the lower-level cloud platform; the preset time interval corresponding to each cloud platform is randomly generated; respectively comparing the received database version identification of the user database of the previous-stage cloud platform and the received database version identification of the user database of the next-stage cloud platform with the database version identification of the local user database; if the database version identification of the local user database is consistent with the received database version identification, no processing is performed; if the database version identification of the local user database is inconsistent with any received database version identification, determining the synchronous data of at least one user according to the two inconsistent database version identifications; and sending the synchronous data of the user to an upper-level cloud platform and a lower-level cloud platform.
In this embodiment, a version identifier is maintained for the user database, and the version identifier is modified correspondingly when the user data is modified. Therefore, the authentication service in each cloud platform can actively acquire the database version identifiers of the user databases of the previous cloud platform and the next cloud platform according to the randomly generated time interval when the periodic synchronization condition is met, so as to judge whether the database version identifiers are the same as the database version identifiers of the local user database of the cloud platform, if the database version identifiers are the same, synchronization is not needed, and if the database version identifiers are different, the synchronization data of at least one user needing synchronization is determined, and the synchronization data of the user can be sent to the previous cloud platform and the next cloud platform by using the method in the embodiment to complete synchronization.
In the above embodiments, the authentication service may be implemented by writing codes according to the own architecture of each cloud platform, for example, by using different types of languages such as JAVA, C + +, and the like. In order to ensure that the authentication services of the cloud platforms at different levels can communicate with each other, in an embodiment of the present invention, the authentication services communicate with the upper-level cloud platform and the lower-level cloud platform through a consistent application programming interface API. Therefore, the loose coupling of the authentication service and the multi-level cloud platform is ensured, and the flexibility is higher.
Fig. 7 is a schematic structural diagram illustrating a user authentication device in a multi-level cloud platform, according to an embodiment of the present invention, where a user authentication device 700 in the multi-level cloud platform is applied to each cloud platform in the multi-level cloud platform, and as shown in fig. 7, the user authentication device 700 in the multi-level cloud platform includes:
the user data maintenance unit 710 is configured to maintain a local user database in the cloud platform, so that the local user database is consistent with user databases in other cloud platforms in the multi-level cloud platform; the local subscriber database stores subscriber data of each subscriber.
A verification unit 720, configured to compare, when receiving a user authentication request sent to the local cloud platform, user data in the user authentication request with user data of a corresponding user in a local user database; if the user data with the consistent version exists in the local user database, judging whether the user authentication data in the user data with the consistent version is the same as the user authentication data in the user data of the latest version of the user in the local user database, and if so, returning an authentication success message;
the verification unit 720 is further configured to send a new version user data acquisition request including the user data in the user authentication request to the upper-level cloud platform if the user data with the consistent version does not exist in the local user database; the user data maintenance unit 710 is further configured to, when receiving the latest version of user data of a corresponding user returned by the upper-level cloud platform, store the latest version of user data in the local user database; the verifying unit 720 is further configured to re-authenticate the user authentication request.
It can be seen that, in the apparatus shown in fig. 7, through the mutual cooperation of the units, a user database capable of maintaining consistency with other cloud platforms is maintained in the cloud platform to store user data of different versions of each user, so that when a user authentication request sent to the cloud platform is received, the user data in the user authentication request is compared with the user data of a corresponding user in the local user database, if the versions are consistent and the user authentication data is the latest, the authentication is successful, and if the versions are inconsistent, the user data of the latest version is obtained for re-authentication. According to the technical scheme, the authentication functions in the cloud platforms can be relatively independent, the consistency of data among the cloud platforms can be guaranteed, the coupling of authentication services in the cloud platforms is greatly reduced, and the development of the authentication services in the cloud platforms is facilitated based on internal system architectures of the cloud platforms; and the load of the top-level cloud platform is reduced, network communication is reduced, and the authentication efficiency is improved.
In an embodiment of the present invention, in the above apparatus, the verification unit 720 is further configured to compare user data in a new version user data acquisition request with user data of a corresponding user in a local user database when receiving the new version user data acquisition request sent by a next-level cloud platform to the local cloud platform; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the next-level cloud platform; if the user data with the consistent version does not exist in the local user database and the upper-level cloud platform exists, forwarding the new-version user data acquisition request to the upper-level cloud platform; the user data maintenance unit 710 is configured to, when receiving user data of the latest version of a corresponding user returned by a previous-stage cloud platform, store the user data of the latest version in a local database, and send the user data of the latest version to a next-stage cloud platform; the verifying unit 720 is further configured to generate a reverse new version user data obtaining request and send the reverse new version user data obtaining request to all next-level cloud platforms to obtain the latest version user data if the user data with the consistent version does not exist in the local user database and the previous-level cloud platform does not exist.
In an embodiment of the present invention, in the above apparatus, the verification unit 720 is further configured to compare user data in the reverse new-version user data acquisition request with user data of a corresponding user in the local user database when receiving the reverse new-version user data acquisition request sent by the previous cloud platform to the local cloud platform; if the user data with the consistent version exists in the local user database, the user data with the consistent version is used as the user data of the latest version of the user and is sent to the upper-level cloud platform; if the user data with the consistent version does not exist in the local user database and the next-level cloud platform exists, forwarding the reverse new-version user data acquisition request to all the next-level cloud platforms; if the user data with the consistent version does not exist in the local user database and the next-level cloud platform does not exist, no processing is performed; the user data maintenance unit 710 is further configured to, when receiving the latest version of user data of a corresponding user returned by the next-level cloud platform, store the latest version of user data in the local database, and send the latest version of user data to the previous-level cloud platform.
In an embodiment of the present invention, in the above apparatus, the user data maintenance unit 710 is configured to, when receiving new user data sent to the local cloud platform from a user, assign a new version identifier to the new user data, and add the new user data to a user data set of a corresponding user in the local user database; and sending the user data set of the corresponding user in the local user database to the upper-level cloud platform and the lower-level cloud platform as the synchronous data of the corresponding user.
In an embodiment of the present invention, in the apparatus, the user data maintenance unit 710 is further configured to compare the received synchronization data of a user sent to the local cloud platform by the previous cloud platform/the next cloud platform with a user data set of a corresponding user in the local user database; if the user data set of the corresponding user in the local user database is the subset of the received synchronous data, replacing the user data set of the corresponding user in the local user database with the synchronous data, and sending the synchronous data to a target cloud platform, wherein when the received synchronous data is sent by an upper-level cloud platform, the target cloud platform is a lower-level cloud platform, and when the received synchronous data is sent by the lower-level cloud platform, the target cloud platform is the upper-level cloud platform; if the user data set of the corresponding user in the local user database has data inconsistent with the synchronous data, integrating the user data set and the synchronous data of the corresponding user in the local user database to obtain a new user data set of the corresponding user, replacing the user data set of the corresponding user in the local user database with the new user data set, and sending the new user data set to an upper-level cloud platform and a lower-level cloud platform as the synchronous data of the corresponding user; and if the user data set of the corresponding user in the local user database is completely consistent with the synchronous data, no processing is performed.
In an embodiment of the present invention, in the above apparatus, the user data maintaining unit 710 is further configured to maintain the version identifier of the local user database according to the user data set of each user in the local user database, and when the user data in the local user database changes, correspondingly modify the version identifier of the local user database; after the preset time interval is reached, requesting a database version identification of a user database of an upper-level cloud platform from the upper-level cloud platform, and requesting a database version identification of a user database of a lower-level cloud platform from the lower-level cloud platform; the preset time interval corresponding to each cloud platform is randomly generated; respectively comparing the received database version identification of the user database of the previous-stage cloud platform and the received database version identification of the user database of the next-stage cloud platform with the database version identification of the local user database; if the database version identification of the local user database is consistent with the received database version identification, no processing is performed; if the database version identification of the local user database is inconsistent with any received database version identification, determining the synchronous data of at least one user according to the two inconsistent database version identifications; and sending the synchronous data of the user to an upper-level cloud platform and a lower-level cloud platform.
In an embodiment of the present invention, in the apparatus, the user authentication data maintenance unit and the verification unit are configured to communicate with the upper-level cloud platform and the lower-level cloud platform through a consistent application programming interface API.
The user authentication device in the multi-level cloud platform provided by the invention can be realized by software, or can be realized by hardware or a combination of hardware and software. For example, in a software implementation, machine executable instructions in the non-volatile memory 850 corresponding to the user authentication device 700 in the multi-level cloud platform may be read by the processor 810 into the volatile memory 840 for execution.
From a hardware level, as shown in fig. 8, which is a schematic structural diagram of a network device hardware according to an embodiment of the present invention, except for the processor 810, the internal bus 820, the network interface 830, the volatile memory 840, and the nonvolatile memory 850 shown in fig. 8, other hardware may be included according to an actual function of the network device, which is not described again.
In various embodiments, the non-volatile memory 850 may be: a storage drive (e.g., hard disk drive), a solid state drive, any type of storage disk (e.g., compact disk, DVD, etc.), or similar storage medium, or a combination thereof. The volatile memory 840 may be: RAM (random Access Memory).
Further, non-volatile memory 850 and volatile memory 840 serve as machine-readable storage media on which machine-executable instructions corresponding to user authentication apparatus 700 in a multi-tier cloud platform executed by processor 810 may be stored.
For the device embodiment, since it basically corresponds to the method embodiment, the relevant points may be referred to the partial description of the method embodiment, and will not be repeated here. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
In summary, according to the technical scheme of the present invention, a user database capable of maintaining consistency with other cloud platforms is maintained in the cloud platform to store user data of different versions of each user, so that when a user authentication request sent to the cloud platform is received, the user data in the user authentication request is compared with the user data of a corresponding user in the local user database, if the versions are consistent and the user authentication data is the latest, the authentication is successful, and if the versions are inconsistent, the user data of the latest version is obtained for re-authentication. According to the technical scheme, the authentication functions in the cloud platforms can be relatively independent, the consistency of data among the cloud platforms can be guaranteed, the coupling of authentication services in the cloud platforms is greatly reduced, and the development of the authentication services in the cloud platforms is facilitated based on internal system architectures of the cloud platforms; and the load of the top-level cloud platform is reduced, network communication is reduced, and the authentication efficiency is improved.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.
Claims (12)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710574685.4A CN107547512B (en) | 2017-07-14 | 2017-07-14 | User authentication method and device in multi-level cloud platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710574685.4A CN107547512B (en) | 2017-07-14 | 2017-07-14 | User authentication method and device in multi-level cloud platform |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107547512A CN107547512A (en) | 2018-01-05 |
| CN107547512B true CN107547512B (en) | 2020-04-17 |
Family
ID=60971025
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710574685.4A Active CN107547512B (en) | 2017-07-14 | 2017-07-14 | User authentication method and device in multi-level cloud platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107547512B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109067903B (en) * | 2018-08-29 | 2021-06-29 | 郑州云海信息技术有限公司 | A cloud platform cascade system |
| CN110928258A (en) * | 2019-12-04 | 2020-03-27 | 北京杰控科技有限公司 | Industrial data acquisition system |
| CN111371843B (en) * | 2020-02-19 | 2021-11-26 | 中国联合网络通信集团有限公司 | Data storage method and device |
| CN114785849A (en) * | 2022-04-27 | 2022-07-22 | 郑州小鸟信息科技有限公司 | Application high-availability method realized based on multi-level node network |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101437194A (en) * | 2007-11-12 | 2009-05-20 | 华为技术有限公司 | Method, system and apparatus for providing user information |
| CN104486421A (en) * | 2014-12-18 | 2015-04-01 | 上海斐讯数据通信技术有限公司 | Realization method for business policy management on cloud platform of wireless business system |
| CN105512346A (en) * | 2016-01-27 | 2016-04-20 | 北京信路威科技股份有限公司 | Vehicle monitoring method based on multistage cloud platform |
| CN105744617A (en) * | 2016-02-25 | 2016-07-06 | 普兴移动通讯设备有限公司 | Synchronization method and device |
| CN106056508A (en) * | 2016-07-01 | 2016-10-26 | 江苏四五安全科技有限公司 | Multistage online training cloud platform |
| CN106302483A (en) * | 2016-08-19 | 2017-01-04 | 上海帜讯信息技术股份有限公司 | Decentralized management method and system |
-
2017
- 2017-07-14 CN CN201710574685.4A patent/CN107547512B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101437194A (en) * | 2007-11-12 | 2009-05-20 | 华为技术有限公司 | Method, system and apparatus for providing user information |
| CN104486421A (en) * | 2014-12-18 | 2015-04-01 | 上海斐讯数据通信技术有限公司 | Realization method for business policy management on cloud platform of wireless business system |
| CN105512346A (en) * | 2016-01-27 | 2016-04-20 | 北京信路威科技股份有限公司 | Vehicle monitoring method based on multistage cloud platform |
| CN105744617A (en) * | 2016-02-25 | 2016-07-06 | 普兴移动通讯设备有限公司 | Synchronization method and device |
| CN106056508A (en) * | 2016-07-01 | 2016-10-26 | 江苏四五安全科技有限公司 | Multistage online training cloud platform |
| CN106302483A (en) * | 2016-08-19 | 2017-01-04 | 上海帜讯信息技术股份有限公司 | Decentralized management method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107547512A (en) | 2018-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11088903B2 (en) | Hybrid cloud network configuration management | |
| US20210165891A1 (en) | Systems and methods for providing multi-node resiliency for blockchain peers | |
| US12137022B2 (en) | Method of scaling reliability of computing network | |
| EP2706719B1 (en) | File synchronization method and device | |
| US11411928B2 (en) | Mobile device identification using second entity matching | |
| CN107547512B (en) | User authentication method and device in multi-level cloud platform | |
| CN110278223B (en) | Video monitoring system and management method of video monitoring resources | |
| CN112261172A (en) | Service addressing access method, device, system, equipment and medium | |
| JP5801482B2 (en) | Method and system for storing and retrieving data from key-value storage | |
| WO2016177130A1 (en) | Method and device for selecting communication node | |
| CN108616613A (en) | A kind of decentralization root domain name service method and system based on block chain | |
| KR20130114575A (en) | Leader arbitration for provisioning services | |
| US20240244414A1 (en) | Session binding relationship processing method and apparatus, electronic device, and readable medium | |
| CN114745413B (en) | Server access control method, device, computer equipment and storage medium | |
| CN108289074B (en) | User account login method and device | |
| CN114866416A (en) | Multi-cluster unified management system and deployment method | |
| CN113886495A (en) | Method and device for verifying block chain data, electronic equipment and storage medium | |
| US20250190629A1 (en) | Blockchain-based data processing method, device, and readable storage medium | |
| US11620273B2 (en) | Message processing node and database in a message processing system and methods of operating the same | |
| WO2016177220A1 (en) | Instant message information storage method and device | |
| CN105141418A (en) | Certificate authentication method and system | |
| US20200099788A1 (en) | Context data management interface for contact center | |
| CN117407437A (en) | Block chain-based data processing method, equipment and readable storage medium | |
| Alshareef et al. | Robust cloud management of MANET checkpoint sessions | |
| CN113612811B (en) | Method, system, equipment and medium for client mounting in multiple channels |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |