A service mesh user state verification method, apparatus, device and medium

Abstract

This invention discloses a service mesh user status verification method, apparatus, device, and medium. The method includes: acquiring an access request sent by a client; wherein the access request carries a predefined level token; parsing the predefined level token to obtain predefined level token information; determining whether the predefined level token information meets the access requirements; and if the predefined level token information meets the access requirements, allowing access to the service mesh. This technical solution, by classifying tokens into different levels, can reduce the parsing time on the service mesh side and improve throughput.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a service mesh user status verification method, apparatus, device, and medium. Background Technology

[0002] Service mesh is typically used to describe the network of microservices that make up an application and the interactions between applications. In the context of a service mesh serving a massive number of users, directly maintaining user state information becomes a challenging problem. The industry standard solution is to use a token to represent a user's login status, and to verify the user's identity by validating the token.

[0003] Currently, conventional token data is large and all use tokens containing complete information. This means that when the server receives each access command, it needs to parse the token containing complete information, which takes a long time and thus limits the access throughput. Summary of the Invention

[0004] This invention provides a service mesh user status verification method, apparatus, device, and medium. By classifying tokens into different levels, the service mesh end can achieve shorter parsing time and improved throughput.

[0005] According to one aspect of the present invention, a service mesh user state verification method is provided, comprising:

[0006] Obtain the access request sent by the client; wherein the access request carries a set level token;

[0007] The set level token is parsed to obtain the set level token information;

[0008] Determine whether the set level token information meets the access requirements;

[0009] If the configured level token information meets the access requirements, access to the service mesh is permitted.

[0010] Optional, also includes:

[0011] If the set level token information does not meet the access requirements, an access denial instruction is generated; wherein, the access denial instruction includes the reason for the access denial;

[0012] The reason for the access ban is sent to the client, allowing the client to change the set level token based on the reason for the access ban in order to continue access.

[0013] Optionally, the set level token information includes level validity period and token level.

[0014] Optionally, determining whether the set level token information meets the access requirements includes:

[0015] Determine whether the validity period of the level and the token level meet the access requirements;

[0016] If both the timeliness of the level and the token level meet the access requirements, then the set level token information meets the access requirements.

[0017] Optional, also includes:

[0018] Determine whether the set level token has expired based on the timeliness information;

[0019] If the set level token becomes invalid, a level token of a higher level than the set level token will be obtained for access.

[0020] Optionally, before obtaining the access request sent by the client, the following may also be included:

[0021] When a client is detected logging in or registering, a random obfuscation code is sent to the client, enabling the client to generate a set-level token based on the random obfuscation code. The set-level token includes a first-level token, a second-level token, and a third-level token. The number of first-level tokens is greater than the number of second-level tokens, the number of second-level tokens is greater than the number of third-level tokens, and the third level is the highest level.

[0022] Optionally, the higher the level of the set level token, the longer the validity period.

[0023] According to another aspect of the present invention, a service mesh user state verification apparatus is provided, comprising:

[0024] An access request acquisition module is used to acquire access requests sent by clients; wherein, the access request carries a set level token;

[0025] The information acquisition module is used to parse the set level token and obtain the set level token information;

[0026] The access requirement judgment module is used to determine whether the set level token information meets the access requirements;

[0027] The service mesh access module is used to allow access to the service mesh if the set level token information meets the access requirements.

[0028] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0029] At least one processor; and

[0030] A memory communicatively connected to the at least one processor; wherein,

[0031] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the service mesh user state verification method according to any embodiment of the present invention.

[0032] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the service mesh user state verification method according to any embodiment of the present invention.

[0033] The technical solution of this invention involves acquiring an access request sent by a client; wherein the access request carries a set-level token; parsing the set-level token to obtain set-level token information; determining whether the set-level token information meets the access requirements; and if the set-level token information meets the access requirements, then access to the service mesh is allowed. This technical solution, by classifying tokens into different levels, enables the service mesh to parse the tokens more quickly, thereby improving throughput.

[0034] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a flowchart of a service mesh user status verification method provided according to Embodiment 1 of the present invention;

[0037] Figure 2 This is a flowchart of a service mesh user status verification method provided according to Embodiment 2 of the present invention;

[0038] Figure 3 This is a schematic diagram of the structure of a service mesh user status verification device according to Embodiment 3 of the present invention;

[0039] Figure 4 This is a schematic diagram of the structure of an electronic device provided according to Embodiment 4 of the present invention. Detailed Implementation

[0040] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0041] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0042] Example 1

[0043] Figure 1 This is a flowchart of a service mesh user status verification method according to Embodiment 1 of the present invention. This embodiment is applicable to situations requiring user status verification. The method can be executed by a service mesh user status device, which can be implemented in hardware and / or software and can be configured in an electronic device with data processing capabilities. Figure 1 As shown, the method includes:

[0044] S110. Obtain the access request sent by the client.

[0045] The access request carries a set-level token. This set-level token can be one of multiple tokens of different levels pre-set by the client. For example, the set-level token may include a first-level token, a second-level token, and a third-level token, where the third-level token can be the highest-level token. The set level can be the lowest-level token among the client's different levels, or it can be set according to actual needs. The access request can be understood as a request from the client to access the service mesh, and it can carry the set-level token. The client can be any terminal of the user. In this embodiment, the access request sent by the client can be obtained.

[0046] In this embodiment, optionally, the higher the level of the set level token, the longer the validity period.

[0047] In this embodiment, the higher the level of the token, the longer its validity period. This setting allows for longer access periods for higher-level tokens, better meeting diverse user access needs.

[0048] S120. Parse the set level token to obtain the set level token information.

[0049] The set-level token can include the level's validity period and the token's level. In this embodiment, the set-level token is parsed to obtain its validity period and level.

[0050] In this embodiment, optionally, the set level token information may include level validity period and token level.

[0051] The validity period of a token level can be characterized as the effective time of the token level, and the number of tokens and the effective time of each level are different. In this embodiment, the validity period of the level tokens can be the validity period within a preset period; the preset period can be set according to actual needs, for example, the preset period can be a period of seven days, one month, or two months.

[0052] For example, the current token's preset period is seven days. The highest level can be the third level, and the validity period of a third-level token can be seven days, with a maximum of one token. The validity period of a second-level token can be two days, with a maximum of three tokens, and the validity periods can be 0-2 days, 2-4 days, and 4-6 days, respectively. The validity period of a first-level token can be one day, and the maximum number of tokens can be seven.

[0053] In this context, the token level can be understood as the specific level information of the token. For example, the token level can be a first level, a second level, or a third level. Furthermore, the token level information can be the user information contained in the token at each level, which can be set according to actual needs. In this embodiment, the information contained in each level of the token is different and can be encrypted according to a set encryption algorithm. For example, the first-level token information only contains user ID information and validity period; the second-level token information only contains user ID information, validity period, and user permission information; and the third-level token information only contains user ID information, validity period, user permission information, and payment information, etc. The third level can be a higher-level token.

[0054] In this embodiment, the information for setting the token level can include the level's validity period and the token level. This setting ensures that the level information data is different for tokens of different levels, resulting in different parsing times. This prevents the parsing of redundant information during each step, thus reducing parsing time.

[0055] S130. Determine whether the set level token information meets the access requirements.

[0056] Here, access requirements can be understood as the microservice access requirements. In this embodiment, it can be determined whether the user information contained in the set level token can meet the microservice access requirements. Specifically, in this embodiment, it can be determined whether the token's validity period and token level meet the microservice access requirements.

[0057] In this embodiment, optionally, determining whether the set level token information meets the access requirements includes: determining whether the level validity period and the token level meet the access requirements; if both the level validity period and the token level meet the access requirements, then the set level token information meets the access requirements.

[0058] In this context, the validity period of the level can be understood as setting the effective period of the level token. In this embodiment, judging the validity period of the level and the token level can be understood as judging whether the validity period of the level token and the token level require access.

[0059] Specifically, in this embodiment, when a client accesses the service mesh, it typically carries the token with the earliest validity period among the lowest levels (e.g., a first-level token with a validity period of 0-1 day). The server verifies the token; it parses the token to obtain the information contained in the token, such as the user ID and validity period, and determines whether the validity period and token level meet the requirements of the microservice access. In this embodiment, during the judgment process, it first determines whether the token has expired, and then determines whether the accessed token level meets the information requirements of the microservice. If both the validity period and the token level pass, the set-level token is allowed to access the microservice; if either or both fail to meet the requirements, an access denial instruction is generated and sent back to the client.

[0060] In this embodiment, it can be determined whether the validity period of the level and the token level meet the access requirements. If both the validity period of the level and the token level meet the access requirements, then the level token information is set to meet the access requirements. In this embodiment, microservice access can be achieved through such a setting, and there will be no situation where redundant information is parsed each time, so the time consumption is shorter and the throughput can be improved.

[0061] In this embodiment, optionally, it further includes: determining whether the set level token has expired based on the timeliness information; if the set level token has expired, obtaining a level token with a higher level than the set level token for access.

[0062] In this context, "expiration" can be understood as the expiration of the validity period of the set-level token. In this embodiment, the validity period of the set-level token can be determined based on the timeliness information; if the validity period of the set-level token has expired, a token of a higher level than the set-level token can be obtained for access.

[0063] For example, the highest-level token is valid for 7 days, and there is one such token. The second-level token is valid for 2 days, and there are three such tokens, with validity periods of 0-2 days, 2-4 days, and 4-6 days respectively. The first-level token is valid for 1 day, and there are 7 such tokens. If, on the 7th day, there are no more second-level tokens available, and their validity periods have expired, then if accessing the microservice requires a second-level token, a third-level token can be selected for access. Furthermore, in this embodiment, the client can also delete expired level tokens to save resources.

[0064] In this embodiment, if even the highest-level token is inaccessible, the client's access is denied. This can be interpreted as the current client not being a legitimate user or the token having expired. In this case, the client needs to log in or register again to obtain a new level token for the next period. Furthermore, in practical applications, this embodiment can also identify the microservice most frequently accessed by the client and determine the relevant information for the lowest-level token based on the access information required by that microservice, thus facilitating the setting of the level token.

[0065] In this embodiment, the tokens can be classified and their validity period can be determined, which can make the service mesh terminal more efficient and convenient to parse the tokens.

[0066] S140. If the set level token information meets the access requirements, then access to the service mesh is allowed.

[0067] In this embodiment, if the validity period of the level in the level token information and the token level meet the access requirements, then access to the service mesh is allowed.

[0068] The technical solution of this invention involves acquiring an access request sent by a client; wherein the access request carries a set-level token; parsing the set-level token to obtain set-level token information; determining whether the set-level token information meets the access requirements; and if the set-level token information meets the access requirements, then access to the service mesh is allowed. This technical solution, by classifying tokens into different levels, enables the service mesh to parse the tokens more quickly, thereby improving throughput.

[0069] Example 2

[0070] Figure 2 This is a flowchart of a service mesh user status verification method according to Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. Specifically, the optimization is as follows: the method further includes: if the set level token information does not meet the access requirements, generating an access denial instruction; wherein, the access denial instruction includes a reason for access denial; sending the reason for access denial to the client, so that the client changes the set level token according to the reason for access denial to continue access. Figure 2 As shown, the method includes:

[0071] S210. Obtain the access request sent by the client.

[0072] The access request carries a set level token.

[0073] S220. Parse the set level token to obtain the set level token information.

[0074] S230. Determine whether the set level token information meets the access requirements.

[0075] S240. If the set level token information does not meet the access requirements, an access denial command will be generated.

[0076] The access denial instruction may include a reason for the access denial; for example, the reason for the access denial may be that the token access time has expired or the access token information is incomplete.

[0077] In this embodiment, if the set level token information does not meet the access requirements, an access denial instruction containing the reason for the access denial can be generated.

[0078] S250. The reason for the access ban is sent to the client, so that the client can change the set level token according to the reason for the access ban in order to continue access.

[0079] In this embodiment, the reason for the access ban can be sent to the client, allowing the client to change the set level token according to the reason for the access ban in order to continue accessing the service mesh.

[0080] Specifically, in this embodiment, when the client receives the access denial instruction, if the access denial instruction has expired, it will continue to access the device using a token with the next expiration time; if the level does not match, it will reselect a token of the corresponding level according to the token level required in the access denial instruction; when the expiration time and the token level do not match, it will select a token of the corresponding level and time.

[0081] In one implementation of this embodiment, when the token access information is incomplete, the service mesh can determine the token level based on the type of microservice accessed by the client and include this information in the access denial instruction.

[0082] In this embodiment, if a certain access information may require access to multiple microservices simultaneously, rather than just one, the service mesh will obtain the token with the highest required access level among the multiple microservices. Based on this, there are two implementation methods: The first method can use the current token for parsing, allowing access to microservices whose access permissions are satisfied by the set token level, while disallowing access to the remaining microservices until the client sends a higher-level token. The second method can currently disallow access to all microservices (including those with sufficient access permissions), and allow access to all microservices only when the client sends a higher-level token.

[0083] The technical solution of this invention involves obtaining an access request sent by a client; wherein the access request carries a set-level token; parsing the set-level token to obtain set-level token information; determining whether the set-level token information meets the access requirements; if the set-level token information does not meet the access requirements, generating an access-denied instruction; wherein the access-denied instruction includes a reason for the access denial; and sending the reason for the access denial to the client, enabling the client to change the set-level token according to the reason for the access denial to continue access. This technical solution, by including a reason for the access denial when issuing an access-denied instruction, ensures that microservice access can be achieved in at most two steps, reducing the amount of data parsed by the grid server and improving throughput.

[0084] In this embodiment, optionally, before obtaining the access request sent by the client, the method further includes: when it is detected that the client is logging in or registering, sending a random obfuscation code to the client, so that the client generates a set level token based on the random obfuscation code.

[0085] The set level tokens can include first-level tokens, second-level tokens, and third-level tokens. The number of first-level tokens is greater than the number of second-level tokens, the number of second-level tokens is greater than the number of third-level tokens, and the third level is the highest level. In this embodiment, the number of set level tokens can satisfy the condition of the longest valid duration / the current level token's valid duration, rounded down to the nearest integer.

[0086] The random obfuscation code can be a code randomly issued by the server when it detects a client logging in or registering. The server can obtain the client ID and store the client ID and the random obfuscation code as a set. There can be a one-to-one correspondence between the random obfuscation code and the client. In this embodiment, after obtaining the random obfuscation code, the client can generate multiple tokens of different levels according to the encryption algorithm, with the number of lower-level tokens exceeding the number of higher-level tokens.

[0087] In this embodiment, when a client is detected logging in or registering, a random obfuscation code is sent to the client, enabling the client to generate a token of a set level based on the random obfuscation code. This configuration, by classifying tokens by level, time period, and quantity, allows the service mesh to parse tokens more quickly, thus improving throughput.

[0088] Example 3

[0089] Figure 3 This is a schematic diagram of the structure of a service mesh user status verification device according to Embodiment 3 of the present invention. Figure 3 As shown, the device includes:

[0090] Access request acquisition module 310 is used to acquire access requests sent by the client; wherein the access request carries a set level token;

[0091] Information acquisition module 320 is used to parse the set level token and acquire set level token information;

[0092] Access requirement judgment module 330 is used to determine whether the set level token information meets the access requirements;

[0093] Service Mesh Access Module 340 is used to allow access to the service mesh if the set level token information meets the access requirements.

[0094] Optionally, the device further includes:

[0095] The access denial instruction generation module is used to generate an access denial instruction if the set level token information does not meet the access requirements; wherein, the access denial instruction includes a reason for access denial;

[0096] The token replacement module is used to send the reason for the access ban to the client, so that the client can replace the token with a set level token according to the reason for the access ban in order to continue access.

[0097] Optionally, the set level token information includes level validity period and token level.

[0098] Optional, access request judgment module 330, specifically used for

[0099] Determine whether the validity period of the level and the token level meet the access requirements;

[0100] If both the timeliness of the level and the token level meet the access requirements, then the set level token information meets the access requirements.

[0101] Optionally, the device further includes: a token invalidation module, used to determine whether the set level token has expired based on the timeliness information;

[0102] If the set level token becomes invalid, a level token of a higher level than the set level token will be obtained for access.

[0103] Optionally, the device further includes: a setting level token generation module, used to send a random obfuscation code to the client before receiving the access request sent by the client, when the client is detected to be logging in or registering, so that the client generates a setting level token according to the random obfuscation code; wherein the setting level token includes a first level token, a second level token, and a third level token, the number of first level tokens is greater than the number of second level tokens, the number of second level tokens is greater than the number of third level tokens, and the third level is the highest level.

[0104] Optionally, the higher the level of the set level token, the longer the validity period.

[0105] The service mesh user status verification device provided in this embodiment of the invention can execute the service mesh user status verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0106] Example 4

[0107] Figure 4This is a schematic diagram of an electronic device according to Embodiment 4 of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0108] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0109] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0110] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the service mesh user state verification method.

[0111] In some embodiments, the service mesh user state verification method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the service mesh user state verification method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the service mesh user state verification method by any other suitable means (e.g., by means of firmware).

[0112] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0113] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0114] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0115] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0116] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0117] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0118] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service mesh user state verification method, characterized in that, include: Obtain the access request sent by the client; wherein the access request carries a set level token; the set level token includes a first level token, a second level token, and a third level token, and the information contained in the tokens of different levels is different; The set level token is parsed to obtain the set level token information; Determine whether the set level token information meets the access requirements; If the configured level token information meets the access requirements, then access to the service mesh is allowed; The information regarding the set level token includes the level's validity period and the token level; Determining whether the set level token information meets the access requirements includes: Determine whether the validity period of the level and the token level meet the access requirements; If both the timeliness of the level and the token level meet the access requirements, then the set level token information meets the access requirements. Before obtaining the access request sent by the client, it also includes: When a client is detected logging in or registering, a random obfuscation code is sent to the client, enabling the client to generate a token of a set level based on the random obfuscation code; wherein, the number of tokens of the first level is greater than the number of tokens of the second level, the number of tokens of the second level is greater than the number of tokens of the third level, and the third level is the highest level.

2. The method according to claim 1, characterized in that, Also includes: If the set level token information does not meet the access requirements, an access denial instruction is generated; wherein, the access denial instruction includes the reason for the access denial; The reason for the access ban is sent to the client, allowing the client to change the set level token based on the reason for the access ban in order to continue access.

3. The method according to claim 1, characterized in that, Also includes: Determine whether the set level token has expired based on the timeliness information; If the set level token becomes invalid, a level token of a higher level than the set level token will be obtained for access.

4. The method according to claim 1, characterized in that, The higher the level of the set level token, the longer the validity period.

5. A service mesh user status verification device, characterized in that, include: An access request acquisition module is used to acquire access requests sent by clients; wherein, the access request carries a set level token; the set level token includes a first level token, a second level token, and a third level token, and the information contained in the tokens of different levels is different; The information acquisition module is used to parse the set level token and obtain the set level token information; The access requirement judgment module is used to determine whether the set level token information meets the access requirements; The service mesh access module is used to allow access to the service mesh if the set level token information meets the access requirements. The information regarding the set level token includes the level's validity period and the token level; The access requirement judgment module is specifically used to determine whether the level validity period and the token level meet the access requirements; if both the level validity period and the token level meet the access requirements, then the set level token information meets the access requirements. A level token generation module is configured to send a random obfuscation code to the client before receiving the access request sent by the client. When the client is detected to be logging in or registering, the module sends the random obfuscation code to the client, which then generates a level token based on the random obfuscation code. The number of tokens for the first level is greater than the number of tokens for the second level, the number of tokens for the second level is greater than the number of tokens for the third level, and the third level is the highest level.

6. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the service mesh user state verification method according to any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the service mesh user state verification method according to any one of claims 1-4.

Images