Login username control method and system, electronic device and storage medium

Abstract

The application provides a login username control method, system, electronic equipment and storage medium. The login username control method is applied to a security agent device and includes the following steps: obtaining address information of a target network system carried in a first access request, and constructing a second access request according to the address information; sending the second access request to the target network system, and receiving a first page description file returned by the target network system; obtaining a first username used by a user when logging in to the security agent device through a client; injecting the first username and a control script into the first page description file to obtain a second page description file; and triggering the control script during an execution process of a login operation on the client, so as to control a second username submitted by the client based on a login page to be consistent with the first username. According to the scheme, the identity impersonation risk caused by the inconsistency between the username input by the user in the login page and the username used by the user when logging in to the security agent device can be eliminated.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to login username control methods, systems, electronic devices and storage media. Background Technology

[0002] As cybersecurity threats become increasingly complex, the zero-trust security concept has gradually become a core idea in enterprise cybersecurity architecture. This concept advocates "continuous verification, never trust," meaning that it does not rely on network location to determine the trustworthiness of access requests, but rather defaults to distrusting any access requests, requiring independent authentication and authorization for each access.

[0003] To implement the above concept, enterprises typically deploy security proxy devices between their internal and external networks. These proxy devices serve as the unified entry point for clients accessing target network systems. Under this access mechanism, users must first log in to the security proxy device via a client. The security proxy device verifies the username and password used by the user during client login. Upon successful verification, a session is established with the client, and a session credential is issued. Subsequently, each access request initiated by the client carries this session credential. The security proxy device verifies the session credential carried in each request, and if verification is successful, it forwards the request to the target network system. Upon receiving the access request forwarded by the security proxy device, the target network system also needs to authenticate the user accessing it. If the user fails to authenticate with the target network system, the target network system will not directly return the requested resource. Instead, it will return the page description file corresponding to its login page. The user must then enter their username and password on the login page and submit it. The target network system verifies the username and password, and only after successful verification is the user allowed to access the requested resource.

[0004] In the aforementioned access mechanism, authentication on the security proxy device side and authentication on the target network system side are independent of each other. To unify user identity management, the security proxy device and the target network system typically interface with the same user identity system. Under this system, each user possesses a unique identifier, which is the username used to log in to the security proxy device and also the username used to log in to the target network system. However, even with the same identifier, because authentication on the security proxy device side and authentication on the target network system side are independent, the username entered by the user on the target network system's login page is not bound by the username already verified on the security proxy device side, still posing a security risk of identity theft. Summary of the Invention

[0005] This application provides a login username control method, system, electronic device, and storage medium to solve one or more of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a login username control method applied to a security proxy device, the method comprising: In response to the first access request initiated by the client, obtain the address information of the target network system carried in the first access request, and construct a second access request based on the address information; Send a second access request to the target network system and receive the first page description file returned by the target network system. The first page description file corresponds to the login page of the target network system. Obtain the first username used by the user when logging into the security agent device via the client; The first username and control script are injected into the first page description file to obtain the second page description file. The control script is triggered during the client's login operation and is used to ensure that the second username submitted by the client based on the login page is consistent with the first username. Send a second page description file to the client so that the client can load the login page based on the second page description file and use control scripts to control the second username.

[0007] Secondly, this application provides another login username control method applied to a client, the method comprising: In response to a user's access request to a target network system, a first access request is constructed, which carries the address information of the target network system. A first access request is sent to the security proxy device, and a second page description file is returned by the security proxy device in response to the first access request. The second page description file is obtained by the security proxy device injecting the first username and control script into the first page description file. The first page description file corresponds to the login page of the target network system and is returned by the target network system in response to the second access request sent by the security proxy device. The second access request is constructed by the security proxy device based on address information. The first username is used by the user when logging into the security proxy device through the client. Load the second page description file to render the login page; In response to a user's login action on the login page, a control script is triggered to ensure that the submitted second username is consistent with the first username.

[0008] Thirdly, embodiments of this application provide a login username control system, including: a client, a security proxy device, and a target network system; The client is used to respond to a user's access request operation triggered for the target network system, construct a first access request, which carries the address information of the target network system; send the first access request to the security proxy device; receive the second page description file returned by the security proxy device; load the second page description file to present the login page; and, in response to the user's login operation triggered on the login page, trigger a control script to ensure that the submitted second username is consistent with the first username. The security proxy device is used to respond to a first access request, obtain address information and construct a second access request; send the second access request to the target network system and receive the returned first page description file, which corresponds to the login page; obtain the first username used by the user when logging into the security proxy device through the client; inject the first username and control script into the first page description file to obtain the second page description file; and send the second page description file to the client. The target network system is used to receive a second access request sent by the security agent device and return a first page description file to the security agent device.

[0009] Fourthly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the methods described above when executing the computer program.

[0010] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described above.

[0011] Compared with related technologies, this application has the following advantages: The login username control scheme provided in this application embodiment involves a second page description file. After receiving a first page description file from the target network system, the security proxy device injects the first username used by the user when logging into the security proxy device via the client, along with a control script, into the first page description file, thus obtaining a second page description file. This second page description file is then sent to the client. In this case, after the client loads the second page description file, the first username and control script are present on the login page. When the user performs a login operation on the login page, the control script is triggered. The control script ensures that the second username submitted by the client based on the login page remains consistent with the first username. In other words, the login username control scheme provided in this application embodiment can forcibly ensure that the username submitted by the client based on the login page remains consistent with the username used by the user when logging into the security proxy device, regardless of the username entered by the user on the login page. This eliminates the risk of identity theft caused by the inconsistency between the username entered by the user on the login page and the username used when logging into the security proxy device.

[0012] Furthermore, since the aforementioned username control process is completed on the client side, there is no need to use a security proxy device to ensure username consistency. As a result, the security proxy device does not need to parse the login data submitted by the user, thus avoiding the problem of security information leakage caused by parsing user login data.

[0013] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0014] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This illustration shows an application scenario diagram of the login username control method provided in the embodiments of this application; Figure 2 A flowchart of a login username control method provided in an embodiment of this application is shown; Figure 3 A flowchart of another login username control method provided in an embodiment of this application is shown; Figure 4 A structural block diagram of a login username control system according to an embodiment of this application is shown; Figure 5 A structural block diagram of a login username control device according to an embodiment of this application is shown; Figure 6 A structural block diagram of a login username control device according to another embodiment of this application is shown; Figure 7 A block diagram of an electronic device used to implement embodiments of this application is shown. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, all models involved in this application (including but not limited to language models or large models) comply with the provisions of relevant laws and standards.

[0017] Under an access mechanism where a security proxy device serves as the unified entry point, authentication on the security proxy device side and authentication on the target network system side are independent. To manage user identities uniformly, the security proxy device and the target network system typically interface with the same user identity system. Under this system, each user possesses a unique identifier, which is the username used to log in to the security proxy device and also the username used to log in to the target network system. That is, under this system, each user is configured with a separate username, which serves as both the authentication credential for logging into the security proxy device and the target network system. However, even with the same identifier, because authentication on the security proxy device side and authentication on the target network system side are independent, the username entered by the user on the target network system's login page is not bound by the username already verified on the security proxy device side, still posing a security risk of identity theft.

[0018] Specifically, a user authenticates with a security proxy device using a username and verifies the access request using the session credentials associated with that username. However, on the login page returned by the target network system, the user enters a different username and password and submits the request. Once the target network system verifies the username and password, the user logs in using this new username. In other words, while the user is authenticated by the security proxy device with one username, they log in to the target network system with a different username, thus performing actions as someone else and creating a security risk of identity theft.

[0019] In related technologies, to address the aforementioned identity impersonation problem, a common approach is to parse the login data submitted by the user on the security proxy device side. Specifically, before forwarding the login request to the target network system, the security proxy device extracts the username submitted by the user from the login request and compares it with a username that has been verified on the security proxy device side. If they do not match, the login request is blocked.

[0020] However, the above solution faces insurmountable obstacles in practical applications. When a user enters and submits login data on the client side, the login data is encrypted on the client side before submission. The encrypted login data is then forwarded to the target network system in ciphertext form via a security proxy device. The security proxy device is in the forwarding path of encrypted communication, and the login request it receives is in ciphertext form, making it impossible to directly extract the username submitted by the user. To decrypt the ciphertext and extract the username, the security proxy device must know the encryption method, key system, and data format used by the target network system. This means that the security proxy device needs to request the aforementioned encryption-related information from the operator of the target network system. However, requesting the operator to provide this information itself constitutes a security information leakage risk. Furthermore, in many real-world scenarios, the target network system is provided by a third-party software developer, and the enterprise operator itself may not possess the technical details required for decryption. Moreover, third-party developers typically do not provide this information externally for security reasons. Therefore, the solution of verifying username consistency by parsing login data is difficult to implement in practice.

[0021] To address the aforementioned technical issues, embodiments of this application provide a login username control scheme for security agent devices and a login username control scheme for clients.

[0022] The core of the login username control scheme applied to security proxy devices lies in the following: The security proxy device obtains the first username used by the user when logging in through a client. This first username and a control script are then injected into the first page description file corresponding to the login page returned by the target network system, resulting in a second page description file which is sent to the client. When the client loads the second page description file to display the login page, the first username and control script already exist on the login page. When the user performs a login operation on the login page, the control script is triggered. Before the client submits the second username based on the login page, it controls the second username by referring to the existing first username on the page, ensuring consistency between the second and first usernames. This eliminates the risk of identity theft due to inconsistencies between the first and second usernames.

[0023] The core of the login username control scheme applied to the client lies in the following: After the client sends a first access request to the security proxy device, it receives a second page description file returned by the security proxy device. This second page description file is obtained by the security proxy device injecting the first username and control script into the first page description file. The client loads the second page description file to display the login page. When the user triggers the login operation, the control script is triggered to ensure that the submitted second username is consistent with the first username.

[0024] The two login username control schemes described above can be used in conjunction. In a scenario where they are used together, the security proxy device is responsible for injecting the first username and the control script, while the client is responsible for loading and triggering the control script. The control script controls the second username on the client side before the second username is submitted, ensuring that the second username is consistent with the first username.

[0025] To help those skilled in the art better understand the technical solutions of the embodiments of this application, some concepts involved in the embodiments of this application will be explained below.

[0026] A client refers to a terminal device or software program running on it that can initiate access requests to the network side, such as a browser. In this embodiment, the client is used to send a first access request to the security proxy device, receive a second page description file returned by the security proxy device, load the second page description file to present the login page, and trigger the control script injected in the second page description file when the user performs a login operation.

[0027] The target network system refers to a network resource system deployed within an enterprise's internal network that a user wishes to access through a security proxy device, such as an application system or data platform deployed within the enterprise's internal network or in the cloud. In this embodiment, the target network system receives access requests forwarded by the security proxy device, returns the first page description file corresponding to the login page when the user fails authentication, verifies the username and password submitted by the user, and allows the user to access its resources after successful verification.

[0028] A security proxy device refers to a proxy gateway device deployed between an enterprise's internal network and external network, serving as a unified entry point for clients to access the target network system. In this embodiment, the security proxy device is used to authenticate the client, forward the client's access request to the target network system, obtain the first page description file returned by the target network system, inject the first username and control script used by the user when logging into the security proxy device into the first page description file, obtain the second page description file, and send the second page description file to the client. Typical forms of security proxy devices include SSL VPN (Secure Sockets Layer Virtual Private Network) gateways or Web VPN (Web Virtual Private Network) gateways.

[0029] To more clearly demonstrate the login username control method provided in the embodiments of this application, an application example of the login username control method provided in the embodiments of this application is first introduced. Please refer to... Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario for the login username control method provided in this application embodiment.

[0030] In this application example, client 101 is a browser program running on a user terminal device, target network system 103 is an office automation (OA) system deployed in the enterprise's internal network, and security proxy device 102 is a Web VPN gateway deployed between the enterprise's internal network and the external network. Both the Web VPN gateway and the OA system are connected to a unified identity authentication system. This system configures a unique identity identifier for each user, which serves as both the username used to log in to the Web VPN gateway and the username used to log in to the OA system. Specifically, employee Zhang San's identity identifier is "zhang san", employee Li Si's is "li si", and employee Wang Wu's is "wang wu".

[0031] The following example illustrates how employee Zhang San accesses the OA system.

[0032] Zhang San initiates an access request to the Web VPN gateway through his browser, and logs in using the first username "zhang san" and the corresponding password. The Web VPN gateway sends the aforementioned first username and password to the unified identity authentication system for verification. After successful verification, a session is established with Zhang San's browser, and session credentials are returned to the browser.

[0033] Subsequently, Zhang San clicked the OA system link in his browser. The browser sent a first access request to the Web VPN gateway, carrying the OA system's address information and the aforementioned session credentials. Upon receiving this first access request, the Web VPN gateway verified the validity of the session credentials. If the verification was successful, it constructed a second access request based on the OA system's address information and sent it to the OA system. Upon receiving this second access request, the OA system, since Zhang San had not yet been authenticated by its own authentication, returned the first page description file corresponding to the login page.

[0034] After receiving the first page description file, the Web VPN gateway obtains the first username "zhang san" used by Zhang San when logging into the Web VPN gateway, injects "zhang san" and the control script into the first page description file to obtain the second page description file, and sends the second page description file to Zhang San's browser.

[0035] After Zhang San's browser loads the second page description file, the login page of the OA system is displayed. Zhang San enters his username and password on the login page and triggers the login operation. Before the login data is submitted, the browser triggers a control script. The control script retrieves the third username entered by Zhang San on the login page and determines whether this third username matches the existing first username "zhang san" on the page. If Zhang San's third username is "zhang san", the control script uses "zhang san" as the submitted second username, meaning the third username entered by the user matches the first username and no changes are needed. If Zhang San's third username is "li si", the control script determines that "li si" does not match "zhang san" and uses the first username "zhang san" as the submitted second username. Finally, the login username submitted to the OA system is "zhang san". After the OA system verifies "zhang san" and the password, Zhang San logs into the OA system as "zhang san".

[0036] In the above process, the control script's control actions on the second username are completed on the client side, and before the second username is submitted to the OA system. The Web VPN gateway does not need to parse the login data submitted by Zhang San to ensure that the submitted second username is consistent with the first username, thus avoiding the risk of Zhang San logging into the OA system as "li si" and operating under someone else's identity.

[0037] To more clearly illustrate the login username control method provided in this application embodiment, another application example of the login username control method provided in this application embodiment will be introduced. Please refer to [link / reference]. Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario for the login username control method provided in this application embodiment.

[0038] In this application example, client 101 is a browser running on a user terminal device, target network system 103 is an Enterprise Resource Planning (ERP) system deployed on the enterprise's internal network, and security proxy device 102 is a Web VPN gateway deployed between the enterprise's internal network and the external network. Both the Web VPN gateway and the ERP system are connected to a unified identity authentication system. This system configures a unique identifier for each user, which serves as both the username used to log in to the Web VPN gateway and the username used to log in to the ERP system. For example, employee Zhao Liu's identifier is "zhao liu," and employee Sun Qi's identifier is "sun qi."

[0039] The following example illustrates how employee Zhao Liu accesses the ERP system.

[0040] Zhao Liu initiates an access request to the Web VPN gateway through his browser, and logs in by entering the first username "zhao liu" and the corresponding password. The Web VPN gateway sends the first username and password to the unified identity authentication system for verification. After successful verification, a session is established with Zhao Liu's browser, and session credentials are returned to the browser.

[0041] Subsequently, Zhao Liu clicked the ERP system link in his browser. The browser sent a first access request to the Web VPN gateway, carrying the ERP system's address information and the aforementioned session credentials. Upon receiving the first access request, the Web VPN gateway verified the validity of the session credentials. If the verification was successful, it constructed a second access request based on the ERP system's address information and sent it to the ERP system. Upon receiving the second access request, the ERP system, since Zhao Liu had not yet passed its own authentication, returned the first page description file corresponding to the login page.

[0042] After receiving the first page description file, the Web VPN gateway obtains the first username "zhao liu" used by Zhao Liu when logging into the Web VPN gateway, injects "zhao liu" and the control script into the first page description file to obtain the second page description file, and sends the second page description file to Zhao Liu's browser.

[0043] After Zhao Liu's browser loads the second page description file, it displays the ERP system's login page. Zhao Liu enters his username and password on the login page and triggers the login operation. Before the login data is submitted, the browser triggers a control script. The control script retrieves the third username Zhao Liu entered on the login page and checks if it matches the existing first username "zhao liu". If the username Zhao Liu entered is "zhao liu", the control script uses "zhao liu" as the submitted second username, meaning the third username matches the first username and requires no change. If the third username Zhao Liu entered is "sun qi", the control script determines that "sun qi" does not match "zhao liu" and uses the first username "zhao liu" as the submitted second username. Finally, the login username submitted to the ERP system is "zhao liu". After the ERP system verifies "zhao liu" and the password, Zhao Liu logs into the ERP system as "zhao liu".

[0044] In the above process, the control script's control actions on the second username are completed on the client side, and before the second username is submitted to the ERP system. The Web VPN gateway does not need to parse the login data submitted by Zhao Liu to ensure that the submitted second username is consistent with the first username, thus avoiding the risk of Zhao Liu logging into the ERP system as "sun qi" and operating under someone else's identity.

[0045] It should be noted that the above application examples of the login username control method provided in the embodiments of this application are merely illustrative examples given to facilitate understanding of the technical solution of this application, and are not intended to limit the application scope of the login username control method provided in the embodiments of this application. The application scenarios of the login username control method provided in the embodiments of this application are not specifically limited, and can be applied to other scenarios of access control based on security proxy devices, such as different network deployment environments or different types of target network systems.

[0046] The technical solutions of this application and how they solve the aforementioned technical problems are described in detail below with specific embodiments. The following related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. Identical or similar concepts or processes may not be described again in some embodiments.

[0047] Figure 2 A flowchart of a login username control method 200 provided in an embodiment of this application is shown. The method is applied to a security agent device and may specifically include steps S201 to S205.

[0048] In step S201, in response to the first access request initiated by the client, the address information of the target network system carried in the first access request is obtained, and a second access request is constructed based on the address information.

[0049] In step S202, a second access request is sent to the target network system, and a first page description file returned by the target network system is received. The first page description file corresponds to the login page of the target network system. In step S203, the first username used by the user when logging into the security agent device through the client is obtained.

[0050] In step S204, the first username and control script are injected into the first page description file to obtain the second page description file; the control script is triggered during the client's login operation and is used to ensure that the second username submitted by the client based on the login page is consistent with the first username.

[0051] In step S205, a second page description file is sent to the client so that the client loads the login page based on the second page description file and uses a control script to control the second username.

[0052] The login username control scheme provided in this application embodiment involves a second page description file. After receiving a first page description file from the target network system, the security proxy device injects the first username used by the user when logging into the security proxy device via the client, along with a control script, into the first page description file, thus obtaining a second page description file. This second page description file is then sent to the client. In this case, after the client loads the second page description file, the first username and control script are present on the login page. When the user performs a login operation on the login page, the control script is triggered. The control script ensures that the second username submitted by the client based on the login page remains consistent with the first username. In other words, the login username control scheme provided in this application embodiment can forcibly ensure that the username submitted by the client based on the login page remains consistent with the username used by the user when logging into the security proxy device, regardless of the username entered by the user on the login page. This eliminates the risk of identity theft caused by the inconsistency between the username entered by the user on the login page and the username used when logging into the security proxy device.

[0053] Furthermore, since the aforementioned username control process is completed on the client side, there is no need to use a security proxy device to ensure username consistency. As a result, the security proxy device does not need to parse the login data submitted by the user, thus avoiding the problem of security information leakage caused by parsing user login data.

[0054] In this embodiment of the application, before the client initiates an access request to the target network system through the security proxy device, a session must first be established between the security proxy device and the client.

[0055] When a user initiates access to the security proxy device through a client, the security proxy device first checks whether the client possesses valid session credentials. For clients without valid session credentials, the security proxy device returns an authentication page to the client, prompting the user to enter a username and password. After the user enters the username and password, the client submits them to the security proxy device, which forwards them to the unified identity authentication system for verification. The unified identity authentication system compares the received username and password with its stored username and password, and if they match, returns a verification result to the security proxy device. Based on this verification result, the security proxy device establishes a session with the client, generates a session credential, and issues it to the client. Simultaneously, it records the username used by the user during login as the first username and associates this first username with the aforementioned session. Subsequently, every access request initiated by the client carries this session credential. The security proxy device verifies the session credential carried in each request, and if the verification is successful, it forwards the request to the target network system.

[0056] In one implementation, the specific process of obtaining the address information of the target network system carried in the first access request and constructing a second access request based on the address information in response to a first access request initiated by the client is as follows: After obtaining the aforementioned session credentials, in response to the user clicking a link to the target network system or entering the access address of the target network system in the browser, the client constructs a first access request, which carries the address information of the target network system and the aforementioned session credentials, and sends the first access request to the security proxy device. Upon receiving the first access request, the security proxy device parses it to obtain the session credentials and the address information of the target network system, and verifies the validity of the session credentials. After successful verification, the security proxy device constructs a second access request based on the parsed address information of the target network system and sends the second access request to the target network system.

[0057] The aforementioned address information refers to information that uniquely identifies the location of a target network system and its resources within the network, such as a Uniform Resource Locator (URL). In one example, the address information of the target network system carried in the first access request is "http: / / intra.oa.com". After the security proxy device parses and obtains this address information, it reconstructs an access request with the target network system as the destination, namely the second access request. The destination of the second access request is "http: / / intra.oa.com". The security proxy device sends the second access request to the target network system corresponding to this address to obtain the corresponding page description file.

[0058] The aforementioned page description file refers to a text file used to define and describe the page structure, content, and style.

[0059] In one implementation, the specific process of sending a second access request to the target network system and receiving the first page description file returned by the target network system is as follows: The security proxy device sends the second access request to the target network system. After receiving the second access request, the target network system authenticates the user associated with the request. If the user fails to pass the authentication of the target network system itself, the target network system does not return the resource requested by the user, but instead returns the first page description file corresponding to the login page. The security proxy device receives the first page description file and uses it as the basis for subsequent injection operations.

[0060] In one example, the first page description file is an HTML (Hyper Text Markup Language) file containing the code for the login form. Once the client loads this page description file, it can display a login page with username and password input fields.

[0061] In one implementation, the specific process of obtaining the first username used by the user when logging into the security proxy device through the client is as follows: After receiving the first access request sent by the client, the security proxy device extracts the session credential from the first access request, and then searches for the associated username in the session information maintained by itself based on the session credential. The username found is the first username used by the user when logging into the security proxy device. This first username is the username submitted by the user when logging into the security proxy device through the client and verified by the unified identity authentication system.

[0062] In one implementation, a control script is triggered during the client's login process. This script ensures that the second username submitted by the client on the login page matches the first username. Specifically, the control script retrieves the third username entered by the user on the login page and determines whether it matches the first username. If they match, either the first or third username is used as the second username; otherwise, the first username is used. Therefore, regardless of the username entered by the user on the login page, the final submitted second username will always match the first username.

[0063] In one example, the first username is "zhangsan". If the user enters "zhangsan" as the third username on the login page, the control script determines that the third username matches the first username and submits "zhangsan" as the second username. If the user enters "lisi" as the third username on the login page, the control script determines that the third username does not match the first username and submits "zhangsan" as the second username. In both cases, the final login username submitted to the target network system is "zhangsan".

[0064] The control script described above performs the control actions on the second username on the client side, and before the second username is submitted to the target network system. Therefore, the security proxy device does not need to parse the user-submitted login data to ensure that the submitted second username is consistent with the first username, eliminating the risk of identity theft caused by a discrepancy between the username entered by the user on the login page and the username used to log in to the security proxy device.

[0065] In one implementation, the first username is injected through the following steps: First, the end position of the page header tag or the beginning position of the page body tag are located in the first page description file. Then, a first script tag is inserted after the end position or the beginning position. This first script tag is configured to declare the first username as a page variable readable by the login page when the second page description file is loaded by the client.

[0066] The specific implementation process for locating the end position of the page header tag or the start position of the page body tag in the first page description file is as follows: The security agent device uses the closing identifier of the page header tag or the starting identifier of the page body tag as the search target, and matches it in the text content of the first page description file to determine the end position of the page header tag or the start position of the page body tag.

[0067] The specific implementation process of inserting the first script tag after the end position or the start position is as follows: After the already located end position or start position, the security agent device concatenates the tag text corresponding to the first script tag into the first page description file, so that the first script tag becomes part of the first page description file.

[0068] The specific configuration process for the first script tag is as follows: The security agent device first constructs a script tag text, which begins with a script start identifier and ends with a script end identifier. Then, a variable declaration statement is written between the script start identifier and the script end identifier. This variable declaration statement is used to declare a page variable and assign the first username to this page variable.

[0069] The page header tag is the area in the page description file used to define page metadata and reference external resources; its ending point is the closing point of this area.

[0070] The main page tag refers to the area in the page description file used to carry the visible content of the page, and its starting position is the beginning position of this area.

[0071] The first script tag is a tag used to embed script code in the page description file. When the client parses the tag, the embedded script code is executed.

[0072] In one example, the first page description file received by the security agent includes a page header area and a page body area. The page header area defines the page title, and the page body area contains a login form with username input fields, password input fields, and a login submit button. The security agent obtains the first username as "zhang san" and inserts a first script tag after the end of the page header tag to obtain a second page description file. This first script tag contains variable declaration statements used to declare a page variable and assign the first username "zhang san" to this page variable.

[0073] When the client loads the second page description file, it parses and executes the variable declaration statements within the first script tag, declaring the first username "zhang san" as a page variable readable by the login page. Subsequently, the control scripts on the login page can directly retrieve the first username by reading this page variable.

[0074] Using this injection method, the first username is sent to the client along with the second page description file and exists in the login page as a page variable, providing a data basis for the control script to control the second username based on the first username during the login operation.

[0075] Inserting the first script tag after the end of the page header tag places the declaration of the first username in the early stages of page parsing. This ensures that the first username exists as a page variable in the page runtime environment when the login form and control scripts in the page body load. Inserting the first script tag after the beginning of the page body tag places the declaration of the first username immediately after visible page content, facilitating the maintenance and understanding of the positional relationship between the injected content and the original content. Both insertion positions achieve the technical goal of declaring the first username as a page-readable variable.

[0076] In one implementation, the control script is injected through the following steps: First, a pre-configured injection rule is read, and a specific function name used to identify the script injection location is determined. This specific function name is the function name of the login trigger function on the login page. Then, in the first page description file, a combined string consisting of the specific function name, parameter parentheses, and the function body start symbol is searched for. Finally, the combined string is replaced with the concatenation of the combined string and the control script, ensuring that the control script resides within the function body of the login trigger function. When the login trigger function is called, the control script executes along with it.

[0077] Injection rules are information pre-configured by the administrator for the login page, indicating the location where control scripts are injected. The injection rules record the login page's address and a script injection location identifier, which uniquely identifies the insertion point of the control script in the page description file.

[0078] A specific function name is a concrete form of script injection location identifier, pointing to the target function on the login page responsible for handling the login submission operation. A concatenated string is a string formed by sequentially piecing together a specific function name, the following parameter parentheses, and the function body's opening symbol.

[0079] The login trigger function is a function on the login page that is called when a user initiates a login operation. This function is responsible for submitting the username and password entered by the user to the target network system.

[0080] The process of reading pre-configured injection rules and determining the specific function name used to identify the script injection location is as follows: The security proxy device first searches the pre-configured injection rule set for an injection rule that matches the page address of the login page corresponding to the current request. After finding a matching injection rule, the security proxy device extracts the script injection location identifier from the injection rule, which is the specific function name.

[0081] The specific process of finding a combined string consisting of a specific function name, parameter parentheses, and the function body start symbol in the first page description file is as follows: The security agent device first concatenates the specific function name, parameter parentheses, and function body start symbol in sequence to form the search target string. Then, the security agent device matches this search target string in the first page description file to locate its occurrence.

[0082] The specific implementation process of replacing the combined string with the concatenated result of the combined string and the control script is as follows: The security agent device first concatenates the control script code to the combined string to form the replacement string. Then, the security agent device replaces the combined string matched in the first page description file with this replacement string. After the replacement is completed, the control script code is located within the login trigger function body, after the function body's start symbol.

[0083] In one example, the login trigger function is named "doLogin". The original definition of this function in the first page description file contains the string "doLogin(){", consisting of the function name "doLogin", parameter parentheses "()", and the function body opening symbol "{". After reading the injection rules, the security agent determines the specific function name as "doLogin", searches for the string "doLogin(){" in the first page description file, and replaces it with a concatenation of "doLogin(){" and control script code. The replaced login trigger function embeds the control script code before the original function body. When a user triggers the login operation on the login page and calls the login trigger function, the control script executes along with the login trigger function, completing the control of the second username before the original submission logic in the login trigger function.

[0084] This control script injection method embeds the control script code directly into the login trigger function's body. It achieves synchronous execution of the control script and the login trigger function without requiring modification to the client configuration or the target network system's login logic. The control script is located at the beginning of the login trigger function's body and executes first each time the function is called, ensuring control over the second username is completed before login submission, effectively preventing bypassing the control script to directly submit login requests.

[0085] In one implementation, the control script is injected through the following steps: First, a pre-configured injection rule is read, and the element selector used to identify the script injection location is determined. Then, a form tag matching the element selector is searched in the first page description file. Finally, a separate script tag containing the control script is inserted after the form tag. The control script is configured to listen for the form tag's submit event when the second page description file is loaded by the client, and to control the second username when the submit event is triggered.

[0086] An element selector is an identifier used to locate specific page elements in a page description file.

[0087] Form tags refer to the areas in the page description file used to contain the login username input field, password input field, and login submit button.

[0088] A standalone script tag is a script tag inserted by a security agent that is independent of the original scripts on the page, and contains complete control script code.

[0089] The specific implementation process of reading pre-configured injection rules and determining the element selector used to identify the script injection location is as follows: The security proxy device searches for an injection rule that matches the page address of the login page corresponding to the current request in the pre-configured injection rule set, and extracts the element selector from the found injection rule.

[0090] The specific implementation process of finding form tags that match the element selector in the first page description file is as follows: the security agent device uses the identification information indicated by the element selector as the matching target, matches it in the text content of the first page description file, and locates the form tag containing the identification information.

[0091] The specific implementation process of inserting a standalone script tag containing control scripts after the form tag is as follows: the security agent device concatenates the standalone script tag containing control script code to the end position of the form tag, making the standalone script tag part of the first page description file, thereby obtaining the second page description file.

[0092] The control script is configured to listen for the submit event of the form tag and control the second username when the submit event is triggered. Specifically, the control script contains event listener registration logic and username control logic. When the client loads the second page description file and parses the independent script tag, the client executes the event listener registration logic in the control script, registering a submit event listener for the form tag. When the user triggers the login operation on the login page, causing the form tag to submit, the submit event listener is triggered, and the username control logic in the control script is then executed. This logic controls the second username submitted by the user through the login page, including checking if the second username matches the first username, and replacing the second username with the first username if they do not match.

[0093] In one example, the element selector specified in the administrator's pre-configured injection rule points to the form tag identified as "loginForm" in the page description file. After reading this injection rule, the security proxy device determines the identity of the form tag indicated by the element selector and searches for a form tag matching that identity in the first page description file. Once a matching form tag is found, the security proxy device inserts a separate script tag containing the control script after the end of that form tag, resulting in a second page description file. When the client loads the second page description file, it parses and executes the control script within the separate script tag and registers a submit event listener for the form tag. When the user enters their username and password and clicks the login submit button, a submit event occurs on the form tag. The control script listens for this submit event and executes immediately, retrieving the entered username and comparing it with the first username. If they do not match, the first username is used instead, ensuring that the username submitted to the target network system is consistent with the first username.

[0094] This script injection method uses a separate script tag after the form tag to control the second username. It allows for listening to form submission events and controlling the second username without modifying the original login trigger function code. The script executes when the form submission event is triggered, ensuring control over the second username is completed before the form data is submitted to the target network system, effectively preventing bypassing the script to submit login requests directly. Furthermore, the script's separation from the original page code through a separate script tag facilitates maintenance and management.

[0095] In one implementation, the client encrypts the login data before submitting it to the security proxy device. This login data includes the username and password entered by the user on the login page, where the username has been controlled by a script to match the first username; that is, the username in the login data is the second username.

[0096] After the client completes encryption, it sends the encrypted login data to the security proxy device. Upon receiving the encrypted login data, the security proxy device does not decrypt it but directly sends it as forwarded data to the target network system. The target network system receives the encrypted login data forwarded by the security proxy device and uses its own decryption key to decrypt the data, obtaining the secondary username and password. The target network system compares the decrypted secondary username and password with its stored username and password. If the verification is successful, the target network system allows the user to access the requested resource and returns the corresponding response data. The security proxy device receives this response data, rewrites the internal resource address, and sends it to the client. If the verification fails, the target network system returns a login error message to the security proxy device, which forwards the error message to the client, allowing the client to re-represent the login page for the user to re-enter the information.

[0097] Since the control script's actions on the username are completed before encryption on the client side, the login data ensures that the second username is consistent with the first username before encryption. Therefore, the security proxy device does not need to decrypt or parse the encrypted login data during the entire proxy forwarding process. This ensures that the second username submitted to the target network system is consistent with the first username, thus achieving consistency control of the login username without decrypting the user login data.

[0098] In one example, the security proxy device can be a Web VPN gateway. WebVPN technology is based on a B / S (Browser / Server) architecture. Users initiate access requests to the Web VPN gateway through a client, i.e., a general-purpose browser. The Web VPN gateway proxies and forwards the page description file returned by the target network system, injecting the first username and control script into the page description file before returning it to the client. Throughout the entire access process, users only need a browser to securely access the target network system; no dedicated VPN client software needs to be pre-installed or configured on the user's terminal. Compared to traditional VPN technologies that require the installation of a separate client program on the user's terminal to establish an encrypted tunnel, Web VPN technology relies entirely on the application layer for secure access, eliminating dependence on specific client software. This solves the problems of high deployment costs, limited compatibility, and complex terminal adaptation caused by installing dedicated client software, offering advantages such as convenient deployment, ease of use, and widespread adoption.

[0099] The security proxy device utilizes Web VPN technology to proxy and forward page description files. Upon receiving the first page description file from the target network system, it injects the first username and control script into that file, generating a second page description file which is then sent to the client. The client's browser loads the page and automatically executes the control script to control the logged-in username. The entire process is completed on the client's browser side; no additional software needs to be installed on the user's terminal besides a standard browser.

[0100] Corresponding to the application examples of the methods provided in the embodiments of this application and the above-described login username control method applied to security agent devices, the embodiments of this application also provide a login username control method applied to a client. For example... Figure 3 As shown, it is a flowchart of another login username control method 300 provided in the embodiment of this application, which may include steps S301 to S304.

[0101] In step S301, in response to the user's access request operation triggered for the target network system, a first access request is constructed, which carries the address information of the target network system.

[0102] In step S302, a first access request is sent to the security proxy device, and a second page description file returned by the security proxy device in response to the first access request is received. The second page description file is obtained by the security proxy device injecting the first username and control script into the first page description file. The first page description file corresponds to the login page of the target network system and is returned by the target network system in response to the second access request sent by the security proxy device. The second access request is constructed by the security proxy device based on address information. The first username is used by the user when logging into the security proxy device through the client.

[0103] In step S303, the second page description file is loaded to present the login page.

[0104] In step S304, in response to the login operation triggered by the user on the login page, a control script is triggered to ensure that the submitted second username is consistent with the first username.

[0105] The login username control scheme applied to the client provided in this application embodiment involves the client sending a first access request to the security proxy device and then receiving a second page description file returned by the security proxy device. This second page description file is obtained by the security proxy device injecting the first username and control script into the first page description file returned by the target network system. The client loads the second page description file to present the login page, where the first username and control script are present. When the user performs a login operation on the login page, the client triggers the control script. Before the second username is submitted, the control script controls the second username with reference to the existing first username on the page, ensuring that the second username is consistent with the first username. Thus, this application scheme can directly ensure that the username submitted by the client is consistent with the username used by the user when logging into the security proxy device, eliminating the risk of identity theft due to inconsistency. Since the above control process is completed on the client side, the security proxy device does not need to parse the login data submitted by the user to achieve username consistency control, thereby avoiding the problem of security information leakage caused by parsing login data.

[0106] In one implementation, the specific process of constructing a first access request in response to a user's access request to a target network system is as follows: the user enters the access address of the target network system in the client browser or clicks a link to the target network system. In response to this user action, the client obtains the address information of the target network system and constructs a first access request carrying that address information. This first access request also carries the session credentials obtained by the user when logging into the security proxy device, which are used by the security proxy device to verify the legitimacy of the client's identity.

[0107] In one implementation, the specific process of sending a first access request to the security proxy device and receiving a second page description file returned by the security proxy device in response to the first access request is as follows: The client sends the constructed first access request to the security proxy device. After receiving the first access request, the security proxy device parses and verifies it. After successful verification, it constructs a second access request based on the address information carried in the first access request, sends the second access request to the target network system, receives the first page description file returned by the target network system, injects the first username and control script into the first page description file to obtain the second page description file, and returns the second page description file to the client. The client receives the second page description file returned by the security proxy device. Here, the first page description file corresponds to the login page of the target network system, and the first username is the username used by the user when logging into the security proxy device through the client.

[0108] In one implementation, the specific process of loading the second page description file to present the login page is as follows: The client parses the received second page description file and renders the login page in the browser window according to the page structure and content defined in the second page description file. This login page includes a username input field, a password input field, and a login submit button. Since the first username and control script have been injected into the second page description file, the first username exists as a page variable on the login page, and the control script is loaded onto the client along with the login page.

[0109] In one implementation, the specific process of triggering a control script in response to a user's login operation on the login page to ensure that the submitted second username matches the first username is as follows: After the user enters their username and password on the login page, they click the login submit button or perform other login-triggered operations. The client responds to these login operations by triggering the execution of the control script. The control script obtains the username entered by the user on the login page as the third username and determines whether the third username matches the existing first username on the page. If they match, the control script uses the third username as the second username to be submitted; otherwise, the control script uses the first username as the second username to be submitted.

[0110] In one implementation, after the control script completes control over the second username, the client encrypts the login data to be submitted. Specifically, the client obtains the second username processed by the control script and the password entered by the user on the login page, and uses the second username and password as the login data to be submitted. The client encrypts the login data using the encryption method required by the target network system, generating encrypted login data. This encrypted login data exists in ciphertext form, and only the target network system can decrypt it using its own decryption key.

[0111] After the client completes encryption, it sends the encrypted login data to the security proxy device. Upon receiving the encrypted login data, the security proxy device does not decrypt or parse it; instead, it directly forwards the encrypted login data as content to the target network system. The target network system receives the encrypted login data forwarded by the security proxy device and uses its own decryption key to decrypt the data, obtaining the secondary username and password contained within. The target network system compares the decrypted secondary username and password with its stored username and password. If the verification is successful, the target network system allows the user to access the requested resource and returns the corresponding response data. The security proxy device receives this response data, rewrites the internal resource address, and sends it to the client. The client loads the rewritten response data to present the requested resource page. If the verification fails, the target network system returns a login error message to the security proxy device. The security proxy device forwards this login error message to the client, which loads the message and re-presents the login page for the user to re-enter their username and password.

[0112] The control script performs its control actions on the second username before encryption on the client side. The second username carried in the encrypted login data is the same as the first username. The security proxy device does not need to decrypt or parse the encrypted login data during the entire proxy forwarding process, thus ensuring that the second username submitted to the target network system is consistent with the first username. This achieves consistency control of the login username without decrypting the user login data.

[0113] Corresponding to the application examples of the methods provided in the embodiments of this application and the above-described login username control method, the embodiments of this application also provide a login username control system. For example... Figure 4 The diagram shown is a structural block diagram of a login username control system 400 according to an embodiment of this application. The system 400 may include: a client 401, a security proxy device 402, and a target network system 403.

[0114] Client 401 is used to respond to a user's access request operation triggered for the target network system, construct a first access request, which carries the address information of the target network system; send the first access request to the security proxy device; receive a second page description file returned by the security proxy device; load the second page description file to present the login page; and, in response to a login operation triggered by the user on the login page, trigger a control script to ensure that the submitted second username is consistent with the first username.

[0115] Security proxy device 402 is used to respond to a first access request, obtain address information and construct a second access request; send the second access request to the target network system and receive a returned first page description file, which corresponds to the login page; obtain the first username used by the user when logging into the security proxy device through the client; inject the first username and control script into the first page description file to obtain a second page description file; and send the second page description file to the client.

[0116] The target network system 403 is used to receive a second access request sent by the security agent device and return a first page description file to the security agent device.

[0117] The functions of each device in the embodiments of this application can be found in the corresponding descriptions in the above methods, and they have corresponding beneficial effects, which will not be repeated here.

[0118] Corresponding to the application examples of the methods provided in the embodiments of this application and the login username control method applied to security agent devices, the embodiments of this application also provide a login username control device. For example... Figure 5 The diagram shown is a structural block diagram of a login username control device 500 according to an embodiment of this application. The device 500 may include: The request processing module 501 is used to respond to the first access request initiated by the client, obtain the address information of the target network system carried in the first access request, and construct a second access request based on the address information.

[0119] The transceiver module 502 is used to send a second access request to the target network system and receive a first page description file returned by the target network system, the first page description file corresponding to the login page of the target network system.

[0120] Username retrieval module 503 is used to retrieve the first username used by the user when logging into the security agent device through the client.

[0121] Injection module 504 is used to inject the first username and control script into the first page description file to obtain the second page description file. The control script is triggered during the client's login operation and is used to ensure that the second username submitted by the client based on the login page is consistent with the first username.

[0122] The sending module 505 is used to send a second page description file to the client so that the client can load the login page based on the second page description file and control the second username using a control script.

[0123] In one implementation, the injection module 504 is specifically used to: find the end position of the page header tag or the start position of the page body tag in the first page description file; and insert a first script tag after the end position or the start position. The first script tag is used to declare the first username as a page variable that can be read by the login page when the second page description file is loaded by the client.

[0124] In one implementation, the injection module 504 is specifically used to: read pre-configured injection rules, determine a specific function name in the injection rules used to identify the script injection location, wherein the specific function name is the function name of the login trigger function of the login page; in the first page description file, search for a combined string consisting of the specific function name, parameter parentheses, and function body start symbol concatenated in sequence; replace the combined string with the concatenation result of the combined string and the control script, so that the control script is located in the function body of the login trigger function, and when the login trigger function is called, the control script is executed together with the login trigger function.

[0125] In one implementation, the injection module 504 is specifically configured to: read pre-configured injection rules and determine the element selector in the injection rules used to identify the script injection location; search for form tags that match the element selector in the first page description file; and insert a separate script tag containing the control script after the form tag. The control script is configured to listen for the form tag's submission event when the second page description file is loaded by the client, and to control the second username when the submission event is triggered.

[0126] In one implementation, the control script is used during the login process on the client to obtain a third username entered by the user on the login page and determine whether the third username matches the first username. If they match, either the first username or the third username is used as the second username; otherwise, the first username is used as the second username.

[0127] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0128] Corresponding to the application examples of the methods provided in the embodiments of this application and the login username control method applied to the client, the embodiments of this application also provide another login username control device. For example... Figure 6 The diagram shown is a structural block diagram of a login username control device 600 according to another embodiment of this application. The device 600 may include: The request construction module 601 is used to construct a first access request in response to an access request operation triggered by a user for a target network system. The first access request carries the address information of the target network system.

[0129] The transceiver module 602 is used to send a first access request to the security proxy device and receive a second page description file returned by the security proxy device in response to the first access request. The second page description file is obtained by the security proxy device injecting a first username and control script into the first page description file. The first page description file corresponds to the login page of the target network system and is returned by the target network system in response to the second access request sent by the security proxy device. The second access request is constructed by the security proxy device based on address information. The first username is used by the user when logging into the security proxy device through a client.

[0130] Load module 603, which is used to load the second page description file to display the login page.

[0131] Trigger module 604 is used to respond to the login operation triggered by the user on the login page and trigger the control script to ensure that the submitted second username is consistent with the first username.

[0132] In one implementation, the control script is used during the login process on the client to obtain a third username entered by the user on the login page and determine whether the third username matches the first username. If they match, either the first username or the third username is used as the second username; otherwise, the first username is used as the second username.

[0133] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here. Figure 7 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 7 As shown, the electronic device includes a memory 701 and a processor 702. The memory 701 stores a computer program that can run on the processor 702. When the processor 702 executes the computer program, it implements the method described in the above embodiments. The number of memories 701 and processors 702 can be one or more.

[0134] The electronic device also includes: The communication interface 703 is used to communicate with external devices and perform data exchange and transmission.

[0135] If the memory 701, processor 702, and communication interface 703 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0136] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0137] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0138] This application also provides a chip, which includes a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0139] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0140] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0141] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0142] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0143] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0144] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0145] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0146] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0147] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0148] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0149] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A login username control method, applied to a security agent device, characterized in that, The method includes: In response to a first access request initiated by the client, the address information of the target network system carried in the first access request is obtained, and a second access request is constructed based on the address information; Send the second access request to the target network system and receive the first page description file returned by the target network system, the first page description file corresponding to the login page of the target network system; Obtain the first username used by the user when logging into the security agent device through the client; The first username and control script are injected into the first page description file to obtain the second page description file; the control script is triggered during the login operation of the client and is used to control the second username submitted by the client based on the login page to be consistent with the first username. The second page description file is sent to the client so that the client loads the login page based on the second page description file and uses the control script to control the second username.

2. The method according to claim 1, characterized in that, The first username was injected through the following steps: Locate the end position of the page header tag or the start position of the page body tag in the first page description file; After the stated end or start position, a first script tag is inserted. This first script tag is used to declare the first username as a page variable that can be read by the login page when the second page description file is loaded by the client.

3. The method according to claim 1, characterized in that, The control script is injected through the following steps: Read the pre-configured injection rules and determine the specific function name used to identify the script injection location in the injection rules. The specific function name is the function name of the login trigger function of the login page. In the first page description file, find the combined string formed by sequentially concatenating the specific function name, parameter parentheses, and function body start symbol; The combined string is replaced with the concatenation result of the combined string and the control script, so that the control script is located in the function body of the login trigger function, and the control script is executed together with the login trigger function when the login trigger function is called.

4. The method according to claim 1, characterized in that, The control script is injected through the following steps: Read the pre-configured injection rules and determine the element selector in the injection rules used to identify the script injection location; In the first page description file, find the form tag that matches the element selector; Insert a separate script tag containing the control script after the form tag; The control script is configured to listen for the submit event of the form tag when the second page description file is loaded by the client, and to control the second username when the submit event is triggered.

5. The method according to claim 1, characterized in that, The control script is used to obtain the third username entered by the user on the login page during the login operation of the client, and determine whether the third username is consistent with the first username; If they match, then the first username or the third username shall be used as the second username; If they do not match, the first username will be used as the second username.

6. A login username control method, applied to a client, characterized in that, The method includes: In response to a user's access request to a target network system, a first access request is constructed, the first access request carrying the address information of the target network system; The system sends a first access request to the security proxy device and receives a second page description file returned by the security proxy device in response to the first access request. The second page description file is obtained by the security proxy device by injecting a first username and control script into the first page description file. The first page description file corresponds to the login page of the target network system and is returned by the target network system in response to the second access request sent by the security proxy device. The second access request is constructed by the security proxy device based on the address information. The first username is used by the user when logging into the security proxy device through the client. Load the second page description file to render the login page; In response to a login operation triggered by the user on the login page, the control script is triggered to ensure that the submitted second username is consistent with the first username.

7. The method according to claim 6, characterized in that, The control script is used to obtain the third username entered by the user on the login page during the login operation of the client, and determine whether the third username is consistent with the first username; If they match, then the first username or the third username shall be used as the second username; If they do not match, the first username will be used as the second username.

8. A login username control system, characterized in that, include: Client, security proxy device, and target network system; The client is configured to respond to an access request triggered by a user for a target network system, construct a first access request, the first access request carrying the address information of the target network system, and send the first access request to the security proxy device. Receive the second page description file returned by the security agent device; Load the second page description file to render the login page; In response to a login operation triggered by the user on the login page, a control script is triggered to ensure that the submitted second username is consistent with the first username; The security proxy device is used to obtain the address information and construct a second access request in response to the first access request; Send the second access request to the target network system and receive the returned first page description file, the first page description file corresponding to the login page; obtain the first username used by the user when logging into the security proxy device through the client; inject the first username and the control script into the first page description file to obtain the second page description file; Send the second page description file to the client; The target network system is configured to receive the second access request sent by the security proxy device and return the first page description file to the security proxy device.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images