Access method and device of legacy system, electronic equipment and storage medium

Abstract

The invention is suitable for the technical field of computer application, and provides a legacy system access method and device, electronic equipment and a storage medium, and the method comprises the steps: determining whether a user is in a logged-in state in a target legacy system; if the target legacy system is not in the logged-in state, sending a legacy system login request to the target legacy system, and receiving user information returned by the target legacy system under the condition that the target legacy system is successfully logged in; otherwise, reading the user information corresponding to the user from the cache; according to the user information, rewriting the legacy system access request to generate a target access request; and sending the target access request to the target legacy system. Therefore, when the user does not log in the legacy system, the login request is sent to the legacy system, the access request of the original legacy system is rewritten, and the legacy system is accessed through the rewritten access request of the legacy system, so that the non-perceptual cross-system login of the user is realized, the explicit login of the user is not needed, and the user experience is improved.

Description

methods, devices, electronic equipment and storage media for accessing legacy systems Technical Field

[0001] This application belongs to the field of computer application technology, and in particular relates to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for accessing legacy systems. Background Technology

[0002] As enterprise technology architectures continue to evolve towards microservices, many legacy systems are difficult to integrate directly into the new system due to historical reasons. These legacy systems, especially early core systems such as user centers and authentication / authorization systems, typically employ non-standardized authentication mechanisms such as private session management and custom tokens. Their interface protocols are incompatible with modern open authorization protocols and common specifications such as JSON network tokens. When newly built gateways or business systems need to call interfaces provided by such legacy systems, the lack of interoperability of authentication mechanisms leads to core problems such as the inability to synchronize user session states and complex coupling between paths and permissions.

[0003] In related technologies, users can be redirected to the legacy system login interface for explicit login within the legacy system, thereby authenticating the user. This method severely impacts the user experience. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device, and computer-readable storage medium for accessing legacy systems, which can solve the problem of poor user experience caused by redirecting users to the legacy system login interface for explicit login in the legacy system and thus authenticating users in related technologies.

[0005] In a first aspect, embodiments of this application provide a method for accessing a legacy system, comprising: responding to a legacy system access request sent by a user, determining whether the user is logged in to a target legacy system, wherein the legacy system access request is used to access the target legacy system; if the user is not logged in to the target legacy system, sending a legacy system login request corresponding to the user to the target legacy system, and receiving user information corresponding to the user returned by the target legacy system if the user successfully logs in to the target legacy system; if the user is logged in to the target legacy system, reading the user information corresponding to the user from a cache; rewriting the legacy system access request according to the user information to generate a target access request to the target legacy system; and sending the target access request to the target legacy system.

[0006] In one possible implementation of the first aspect, before determining whether the user is logged in to the target legacy system in response to a legacy system access request sent by the user, the method further includes:

[0007] Obtain the access request sent by the user, wherein the access request includes a request path and a request header; if the request path of the access request includes a first preset field and the request header of the access request includes a second preset field, determine that the access request is a legacy system access request.

[0008] Optionally, in another possible implementation of the first aspect, the aforementioned legacy system access request includes a request header, and the determination of whether a user is logged in to the target legacy system includes: parsing the request header of the legacy system access request to determine the user's user identifier; constructing a unique session key corresponding to the user based on the user identifier; querying whether the cache contains a session corresponding to the unique session key; if the cache contains a session corresponding to the unique session key, determining that the user is logged in to the target legacy system; if the cache does not contain a session corresponding to the unique session key, determining that the user is not logged in to the target legacy system.

[0009] Optionally, in another possible implementation of the first aspect, after receiving the user information returned by the target legacy system upon successful login to the target legacy system, the method further includes: establishing a session corresponding to a unique session key in the cache; and storing the user information in the session.

[0010] Optionally, in another possible implementation of the first aspect, the above-mentioned sending a legacy system login request corresponding to the user to the target legacy system and receiving the user information corresponding to the user returned by the target legacy system upon successful login includes: generating a legacy system login request corresponding to the user based on the user identifier; sending the legacy system login request to the target legacy system; and receiving the user information corresponding to the user returned by the target legacy system upon successful login.

[0011] Optionally, in another possible implementation of the first aspect, the legacy system access request includes a request path and a request header. The rewriting of the legacy system access request based on user information to generate a target access request for the target legacy system includes: modifying the request path of the legacy system access request according to the access rules of the target legacy system; modifying the request header of the legacy system access request according to user information and access rules; and determining the modified legacy system access request as the target access request.

[0012] Secondly, this application also provides a legacy system access device, comprising: a first determining module, configured to determine whether the user is logged in to a target legacy system in response to a legacy system access request sent by a user, wherein the legacy system access request is used to access the target legacy system; a receiving module, configured to send a legacy system login request corresponding to the user to the target legacy system when the user is not logged in to the target legacy system, and to receive user information corresponding to the user returned by the target legacy system upon successful login to the target legacy system; a reading module, configured to read the user information corresponding to the user from a cache when the user is logged in to the target legacy system; a generating module, configured to rewrite the legacy system access request based on the user information to generate a target access request to the target legacy system; and a sending module, configured to send the target access request to the target legacy system.

[0013] In one possible implementation of the second aspect, the aforementioned legacy system access device further includes: an acquisition module, configured to acquire an access request sent by a user, wherein the access request includes a request path and a request header; and a second determination module, configured to determine that the access request is a legacy system access request when the request path of the access request includes a first preset field and the request header of the access request includes a second preset field.

[0014] Optionally, in another possible implementation of the second aspect, the aforementioned legacy system access request includes a request header; correspondingly, the aforementioned first determining module includes: a first determining unit, used to parse the request header of the legacy system access request to determine the user's user identifier; a constructing unit, used to construct a unique session key corresponding to the user based on the user identifier; a querying unit, used to query whether the cache includes a session corresponding to the unique session key; a second determining unit, used to determine that the user is logged in to the target legacy system if the cache includes a session corresponding to the unique session key; and a third determining unit, used to determine that the user is not logged in to the target legacy system if the cache does not include a session corresponding to the unique session key.

[0015] Optionally, in another possible implementation of the second aspect, the access device for the aforementioned legacy system further includes: an establishment unit for establishing a session corresponding to a unique session key in the cache; and a storage unit for storing user information in the session.

[0016] Optionally, in another possible implementation of the second aspect, the receiving module includes: a first generating unit, configured to generate a legacy system login request corresponding to the user based on the user identifier; a sending unit, configured to send the legacy system login request to the target legacy system; and a receiving unit, configured to receive the user information corresponding to the user returned by the target legacy system upon successful login to the target legacy system.

[0017] Optionally, in another possible implementation of the second aspect, the legacy system access request includes a request path and a request header; correspondingly, the generation module includes: a first modification unit, used to modify the request path of the legacy system access request according to the access rules of the target legacy system; a second modification unit, used to modify the request header of the legacy system access request according to user information and access rules; and a fourth determination unit, used to determine the modified legacy system access request as the target access request.

[0018] Thirdly, this application also provides an electronic device. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement any of the implementations of the first aspect described above.

[0019] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method of any of the implementations of the first aspect described above.

[0020] Fifthly, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute any of the implementation methods of the first aspect described above.

[0021] The beneficial effects of this application embodiment compared with the prior art are as follows: when a user accesses a legacy system, if the user is not logged into the legacy system, the gateway is used to send a login request to the legacy system and obtain user information; if the user is already logged into the legacy system, the user information is directly read from the cache, and the original legacy system access request is rewritten according to the user information, so as to access the legacy system through the rewritten legacy system access request, thereby realizing cross-system login without the user's awareness, without the need for the user to explicitly log in, and improving the user experience. Attached Figure Description

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

[0023] Figure 1 is a flowchart illustrating a legacy system access method according to an embodiment of this application; Figure 2 is a data interaction diagram illustrating a legacy system access method according to an embodiment of this application; Figure 3 is a data interaction diagram illustrating a legacy system access method according to another embodiment of this application; Figure 4 is a data interaction diagram illustrating a legacy system access method according to yet another embodiment of this application; Figure 5 is a structural schematic diagram illustrating a legacy system access device according to an embodiment of this application; Figure 6 is a structural schematic diagram illustrating an electronic device according to an embodiment of this application. Detailed Implementation

[0024] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0025] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0026] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0028] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0030] As enterprise technology architectures continue to evolve towards microservices, many legacy systems are difficult to integrate directly into the new system due to historical reasons. These legacy systems, especially early core systems such as user centers and authentication / authorization systems, typically employ non-standardized authentication mechanisms such as private session management and custom tokens. Their interface protocols are incompatible with modern open authorization protocols and common specifications such as JSON network tokens. When newly built gateways or business systems need to call interfaces provided by such legacy systems, the lack of interoperability of authentication mechanisms leads to core problems such as the inability to synchronize user session states and complex coupling between paths and permissions.

[0031] In related technologies, users can be redirected to the legacy system login interface for explicit login within the legacy system, thereby authenticating the user. This method severely impacts the user experience.

[0032] Alternatively, the legacy system can be modified so that its interface protocol is the same as that of the newly built gateway or business system. However, this method has a long implementation cycle, high complexity, and poor performance.

[0033] Based on this, this application provides a method, apparatus, electronic device, storage medium, and computer program for accessing legacy systems.

[0034] The following description, with reference to the accompanying drawings, details the methods, apparatus, electronic devices, storage media, and computer programs for accessing legacy systems provided in this application.

[0035] Figure 1 shows a flowchart of an access method for a legacy system provided in an embodiment of this application.

[0036] Step 101: In response to the legacy system access request sent by the user, determine whether the user is logged in to the target legacy system, wherein the legacy system access request is used to access the target legacy system.

[0037] It should be noted that the legacy system access method of this application embodiment can be executed by the legacy system access device of this application embodiment. The legacy system access device of this application embodiment can be configured in any electronic device to execute the legacy system access method of this application embodiment.

[0038] In this application embodiment, the legacy system access method provided can be applied to a gateway.

[0039] As one possible implementation, the target legacy system could be a user center system, which could include functions such as user identity management, permission allocation, and organizational structure, and could provide a series of internal interfaces to the outside world. These interfaces typically use session-based or custom user token-based authentication methods and do not expose standard authentication interfaces.

[0040] One possible implementation is that a legacy system access request can be a request to access a target legacy system. The received access request can be parsed to determine if it is indeed a legacy system access request. If it is, the request can be parsed to identify the corresponding user identifier and then used to determine if the user is logged in to the target legacy system.

[0041] Optionally, before step 101 above, the method may further include: obtaining an access request sent by the user, wherein the access request includes a request path and a request header; and determining that the access request is a legacy system access request if the request path of the access request includes a first preset field and the request header of the access request includes a second preset field.

[0042] In one possible implementation of this application, a global filter can be defined in the gateway. First, the access request sent by the user can be obtained, which may include a request path, request headers, and a request body. Next, the global filter can parse the request path. When the request path includes a first preset field, the request header can be analyzed. If the request header includes a second preset field, it can be determined that the access request is a legacy system access request for accessing the target legacy system. That is, the global filter intercepts the access request and performs subsequent processing. The first and second preset fields can be pre-defined. When the access request is for accessing the target legacy system, the request path must include the first preset field, and the request header must include the second preset field to identify the access request for accessing the target legacy system.

[0043] As an example, the request path for a legacy system access request can consist of a first preset field and the actual request path of the target legacy system. However, it is not limited to this.

[0044] For example, if the first preset field is " / ucapi" and the second preset field is "X-Legacy-Auth=uc", then when the request path of the access request includes " / ucapi" and the request header includes "X-Legacy-Auth=uc", it can be determined that the access request is a legacy system access request. For example, the request path of this legacy system access request could be " / ucapi / legacy-api / v1 / getUserData", where " / ucapi" is the first preset field and " / legacy-api / v1 / getUserData" is the actual request path of the target legacy system.

[0045] This allows for dual authentication via the request path and request headers, preventing attackers from bypassing the authentication process of logging into the target legacy system by modifying the request path.

[0046] Optionally, when the user is already logged into the newly built business system, the legacy system access request can carry the user's user identifier in the request header. Therefore, the request header of the legacy system access request can be parsed to determine the user's user identifier. That is, in one possible implementation of this application, the aforementioned legacy system access request includes a request header, and the aforementioned step 101 may include: parsing the request header of the legacy system access request to determine the user's user identifier; constructing a unique session primary key corresponding to the user based on the user identifier; querying whether the cache includes a session corresponding to the unique session primary key; if the cache includes a session corresponding to the unique session primary key, determining that the user is logged in in the target legacy system; if the cache does not include a session corresponding to the unique session primary key, determining that the user is not logged in in the target legacy system.

[0047] In one possible implementation of this application, a cache can be maintained to store the sessions of users who have successfully logged into the target legacy system. The sessions may include user information returned by the target legacy system, such as user tokens, token validity periods, and user permissions.

[0048] It should be noted that the above examples are merely illustrative. In actual use, the specific content included in the user information can be determined according to actual usage needs and application scenarios. This application embodiment does not limit this.

[0049] Next, when a legacy system access request is received, the request header can be parsed. For example, the user's identifier can be determined by extracting the value of the preset user identifier field in the request header. Based on the preset format, a unique session primary key corresponding to the user identifier, loginkey, can be constructed. The cache can be checked to see if a session corresponding to loginkey exists and whether the user token in the session is within the valid time. If a session corresponding to loginkey exists and the user token in the session is within the valid time, it can be determined that the user is logged in to the target legacy system. Otherwise, if the cache does not contain a session corresponding to loginkey, or if the user token in the session corresponding to loginkey has expired (not within the valid time), it can be determined that the user is not logged in to the target legacy system.

[0050] For example, assuming the default user identifier field in the request header is "X-User-ID" and the default format of "loginkey" is "legacy_session:user identifier", then the value corresponding to the "X-User-ID" field can be extracted, let's say it's "CC", and a loginkey of "legacy_session:CC" can be constructed. Then, a query can be performed in the cache (such as a Redis cache) to check if the session corresponding to "legacy_session:CC" is included.

[0051] Step 102: If the user is not logged in to the target legacy system, send a legacy system login request corresponding to the user to the target legacy system, and receive the user information corresponding to the user returned by the target legacy system if the user successfully logs in to the target legacy system.

[0052] In one possible implementation, when a user is not logged into the target legacy system, a login request for that user's corresponding legacy system can be sent to the target legacy system, allowing the user to log in through the corresponding legacy system login request. After successful login, the user's information can be received from the target legacy system.

[0053] In one possible implementation of this application, when the user is not logged in to the target legacy system, the request body of the legacy system access request can be stored in the cache, so that the target access request can be constructed based on the request body in the cache later.

[0054] For example, the Flux.cache() function can be used to store the request body of legacy system access requests in a cache for later retrieval of the request body.

[0055] Optionally, step 102 above may include: generating a legacy system login request corresponding to the user based on the user identifier; sending the legacy system login request to the target legacy system; and receiving the user information corresponding to the user returned by the target legacy system if the user successfully logs in to the target legacy system.

[0056] In one possible implementation of this application, the user identifier can be injected into a preset legacy system login request to generate a legacy system login request corresponding to this user. The login path of the target legacy system can be obtained, and the legacy system login request interface can be called asynchronously to send a legacy system login request to the target legacy system according to the login path of the target legacy system. If the user successfully logs into the target legacy system, the user information corresponding to the user returned by the target legacy system can be received. The user information can be in JSON object format.

[0057] For example, the legacy system login request interface can be asynchronously called through WebClient to achieve asynchronous non-blocking automatic login, thereby not affecting the performance of the main thread and thus improving the user experience.

[0058] In one possible implementation, if login to the target legacy system fails, the target legacy system will return a login failure message according to preset rules. Upon receiving this login failure message from the target legacy system, a login failure message can be returned to the frontend, allowing the frontend to display a permission-unauthorized reminder to the user and provide manual login or refresh retry controls. In this way, upon receiving a login failure message from the target legacy system, the login failure message is directly returned to the frontend instead of automatically retrying, thus preventing system cascading failures.

[0059] It should be noted that the number of automatic retries can be preset according to actual needs and specific use cases. When a login failure message is received from the target legacy system, the system can automatically retries according to the preset number of automatic retries to improve the success rate of automatic login while ensuring system performance.

[0060] Optionally, after step 102 above, the process may further include: establishing a session corresponding to the unique session key in the cache; and storing user information in the session.

[0061] In one possible implementation of this application, a session corresponding to the user's login key can be established in the cache, and the user information can be stored in the session. This allows for maintaining the user's login state in the target legacy system through caching, avoiding the need for repeated logins when accessing the target legacy system subsequently. This improves system response speed, reduces resource waste, and further enhances the user experience.

[0062] Step 103: If the user is already logged in in the target legacy system, read the user information corresponding to the user from the cache.

[0063] As one possible implementation, when a user is logged into the target legacy system (i.e., the user's session is cached and the user token in the session is within its validity period), the user's information can be read from the cached session. This allows access to the target legacy system based on the user information.

[0064] As one possible implementation, after receiving user information returned by the target legacy system, or after reading user information from the cache, the requested function corresponding to the legacy system access request can be analyzed. Based on the user permissions in the user information, it can be determined whether the user's user permissions include the aforementioned requested function, i.e., whether the user has permission to access the requested function. If yes, subsequent steps such as generating the target access request are executed. If no, a login failure message can be returned to the front end so that the front end can display a permission-unauthorized reminder to the user.

[0065] Step 104: Based on the user information, rewrite the legacy system access request to generate a target access request for the target legacy system.

[0066] One possible implementation is to read the request body of the legacy system access request stored in the cache, and rewrite the legacy system access request according to the user information and the request body of the legacy system access request to generate a target access request for the target legacy system, thereby accessing the target legacy system through the target access request.

[0067] Optionally, the legacy system access request includes a request path and a request header. Based on the user information, the legacy system access request is rewritten to generate a target access request for the target legacy system. This includes: modifying the request path of the legacy system access request according to the access rules of the target legacy system; modifying the request header of the legacy system access request according to the user information and access rules; and determining the modified legacy system access request as the target access request.

[0068] In one possible implementation of this application, the request path of the legacy system access request can be modified according to the access rules of the target legacy system, such as the request path.

[0069] As an example, the request path of a legacy system access request consists of a first preset field and the actual request path specified in the access rules of the target legacy system. Therefore, the first preset field in the request path of the legacy system access request can be deleted. For example, if the request path of the legacy system access request is " / ucapi / legacy-api / v1 / getUserData", where " / ucapi" is the first preset field, then the request path can be modified to " / legacy-api / v1 / getUserData".

[0070] Next, user information (such as user ID, user token, etc.) can be injected into the request header of the legacy system access request, and other specified fields can be injected into the request header according to the preset access rules, such as device tokens used for device consistency verification, thereby modifying the request header of the legacy system access request.

[0071] Next, the request body of the legacy system access request can be read from the cache, and then combined with the modified request path and request headers to generate the target access request. In this way, context passing across systems can be achieved.

[0072] Step 105: Send the target access request to the target legacy system.

[0073] As one possible implementation, the request path of the target access request can be set in the exchange's route attribute, and chain.filter() can be called to further pass the target access request to the target legacy system, so that the target legacy system can execute the corresponding business service according to the target access request.

[0074] Optionally, after sending the target access request to the target legacy system, doFinally can be used to clean up the network buffer corresponding to the request body of the legacy system access request in the cache, so that the network buffer is properly released to prevent memory leaks.

[0075] Furthermore, in the entire reactive processing chain of this application embodiment, it is possible to pass data without relying on ThreadLocal, thereby ensuring that even if the processing flow of the access request jumps between multiple threads, its key information (such as user login status, user information, etc.) will not be lost.

[0076] It should be noted that the request path, user identifier, first preset field, second preset field, etc. listed in the above embodiments are only exemplary. In actual use, they can be determined according to actual usage needs and application scenarios. This application embodiment does not limit them.

[0077] The legacy system access method provided in this application, when a user accesses the legacy system, if the user is not logged in, sends a login request to the legacy system and obtains user information through the gateway; if the user is already logged in, the user information is directly read from the cache, and the original legacy system access request is rewritten based on the user information, so as to access the legacy system through the rewritten legacy system access request, thereby realizing cross-system login without the user's awareness, without the need for explicit login, and improving the user experience.

[0078] Figure 2 is a data interaction diagram of an access method for a legacy system provided in an embodiment of this application.

[0079] As shown in Figure 2, the access method for this legacy system includes the following steps: Step 201, the client sends an access request to the gateway; Step 202, the gateway receives the access request sent by the client; Step 203, it determines whether the access request is a legacy system access request. If so, it extracts the user identifier from the legacy system access request and constructs a loginkey based on the user identifier; Step 204, the gateway sends a query instruction to the cache based on the loginkey corresponding to the user; Step 205, the cache receives the query instruction and returns the user information in the session to the gateway; Step 206, the gateway receives the user information; Step 207, the gateway rewrites the request path of the legacy system access request and rewrites the request header of the legacy system access request based on the user information to generate a target access request; Step 208, the gateway sends the target access request to the target legacy system; Step 209, the target legacy system receives the target access request, executes the corresponding business service according to the target access request, and returns the execution result to the gateway; Step 210, the gateway receives the execution result sent by the target legacy system and returns the execution result to the client.

[0080] Figure 3 is a data interaction diagram of an access method for a legacy system provided in another embodiment of this application.

[0081] As shown in Figure 3, the access method for this legacy system includes the following steps: Step 301, the client sends an access request; Step 302, the gateway receives the access request sent by the client; Step 303, it determines whether the access request is a legacy system access request. If so, it extracts the user identifier from the legacy system access request and constructs a loginkey based on the user identifier; Step 304, the gateway sends a query instruction to the cache based on the loginkey corresponding to the user; Step 305, the cache receives the query instruction and sends a query failure message to the gateway; Step 306, the gateway receives the query failure message; Step 307, the gateway stores the request body of the legacy system access request; Step 308, it asynchronously sends a legacy system login request to the target legacy system; Step 309, the target legacy system receives the legacy system login request. Step 310: The gateway receives the user information and sends a storage instruction to the cache based on the user information. Step 311: The cache receives the storage instruction and constructs the session corresponding to the user based on the user information. Step 312: The gateway rewrites the request path of the legacy system access request and rewrites the request header of the legacy system access request based on the user information to generate the target access request. Step 313: The gateway sends the target access request to the target legacy system. Step 314: The target legacy system receives the target access request, executes the corresponding business service according to the target access request, and returns the execution result to the gateway. Step 315: The gateway receives the execution result sent by the target legacy system, releases the network buffer, and returns the execution result to the client.

[0082] Figure 4 is a data interaction diagram of an access method for a legacy system provided in another embodiment of this application.

[0083] As shown in Figure 4, the access method for this legacy system includes the following steps: Steps 401-408 are the same as steps 301-308 above, and will not be repeated here; Step 409, the target legacy system receives the legacy system login request, and returns login failure information to the gateway if the verification fails; Step 410, the gateway receives the login failure information sent by the target legacy system, and returns the login failure information to the client.

[0084] Through the above process, when a user accesses the legacy system, if the user is not logged into the legacy system, the gateway sends a login request to the legacy system and retrieves user information. If the user is already logged into the legacy system, the user information is directly read from the cache, and the original legacy system access request is rewritten based on the user information. The rewritten legacy system access request is then used to access the legacy system, thereby enabling users to log in to the system without being aware of it, without requiring the user to explicitly log in, thus improving the user experience.

[0085] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0086] Corresponding to the legacy system access method described in the above embodiments, Figure 5 shows a structural block diagram of the legacy system access device provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0087] Referring to Figure 5, the device 50 includes: a first determining module 51, configured to determine whether the user is logged in to the target legacy system in response to a legacy system access request sent by the user, wherein the legacy system access request is used to access the target legacy system; a receiving module 52, configured to send a legacy system login request corresponding to the user to the target legacy system when the user is not logged in to the target legacy system, and to receive user information corresponding to the user returned by the target legacy system when the user successfully logs in to the target legacy system; a reading module 53, configured to read the user information corresponding to the user from a cache when the user is logged in to the target legacy system; a generating module 54, configured to rewrite the legacy system access request according to the user information to generate a target access request to the target legacy system; and a sending module 55, configured to send the target access request to the target legacy system.

[0088] In practical use, the legacy system access device provided in this application embodiment can be configured in any electronic device to execute the aforementioned legacy system access method.

[0089] The legacy system access device provided in this application embodiment, when a user accesses the legacy system, if the user is not logged in, uses a gateway to send a login request to the legacy system and obtain user information; if the user is already logged in, it directly reads the user information from the cache and rewrites the original legacy system access request based on the user information, so as to access the legacy system through the rewritten legacy system access request, thereby realizing cross-system login without the user's awareness, without the need for explicit login, and improving the user experience.

[0090] In one possible implementation of this application, the legacy system access device 50 further includes: an acquisition module, configured to acquire an access request sent by a user, wherein the access request includes a request path and a request header; and a second determination module, configured to determine that the access request is a legacy system access request when the request path of the access request includes a first preset field and the request header of the access request includes a second preset field.

[0091] Optionally, in another possible implementation of this application, the legacy system access request includes a request header; correspondingly, the first determining module 51 includes: a first determining unit, used to parse the request header of the legacy system access request to determine the user's user identifier; a constructing unit, used to construct a unique session key corresponding to the user based on the user identifier; a querying unit, used to query whether the cache includes a session corresponding to the unique session key; a second determining unit, used to determine that the user is logged in in the target legacy system if the cache includes a session corresponding to the unique session key; and a third determining unit, used to determine that the user is not logged in in the target legacy system if the cache does not include a session corresponding to the unique session key.

[0092] Optionally, in another possible implementation of this application, the access device 50 for the legacy system further includes: an establishment unit for establishing a session corresponding to a unique session key in the cache; and a storage unit for storing user information in the session.

[0093] Optionally, in another possible implementation of this application, the receiving module 52 includes: a first generating unit, configured to generate a legacy system login request corresponding to the user based on the user identifier; a sending unit, configured to send the legacy system login request to the target legacy system; and a receiving unit, configured to receive the user information corresponding to the user returned by the target legacy system if the user successfully logs into the target legacy system.

[0094] Optionally, in another possible implementation of this application, the legacy system access request includes a request path and a request header; correspondingly, the generation module 54 includes: a first modification unit, used to modify the request path of the legacy system access request according to the access rules of the target legacy system; a second modification unit, used to modify the request header of the legacy system access request according to user information and access rules; and a fourth determination unit, used to determine the modified legacy system access request as the target access request.

[0095] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0097] To implement the above embodiments, this application also proposes an electronic device.

[0098] Figure 6 is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0099] As shown in Figure 6, the above-mentioned electronic device 200 includes: a memory 210 and at least one processor 220, a bus 230 connecting different components (including the memory 210 and the processor 220), the memory 210 storing a computer program, and when the processor 220 executes the program, it implements the legacy system access method described in the embodiments of this application.

[0100] Bus 230 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0101] Electronic device 200 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 200, including volatile and non-volatile media, removable and non-removable media.

[0102] Memory 210 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 240 and / or cache memory 250. Electronic device 200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 260 may be used to read and write non-removable, non-volatile magnetic media (not shown in FIG. 6, commonly referred to as "hard disk drives"). Although not shown in FIG. 6, disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disk drives for reading and writing to removable non-volatile optical disks (e.g., CD-ROMs, DVD-ROMs, or other optical media) may be provided. In these cases, each drive may be connected to bus 230 via one or more data media interfaces. Memory 210 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0103] A program / utility 280 having a set (at least one) of program modules 270 may be stored in, for example, memory 210. Such program modules 270 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 270 typically perform the functions and / or methods described in the embodiments of this application.

[0104] Electronic device 200 can also communicate with one or more external devices 290 (e.g., keyboard, pointing device, display 291, etc.), and with one or more devices that enable a user to interact with electronic device 200, and / or with any device that enables electronic device 200 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 292. Furthermore, electronic device 200 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 293. As shown, network adapter 293 communicates with other modules of electronic device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0105] The processor 220 performs various functional applications and data processing by running programs stored in the memory 210.

[0106] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the legacy system access method in the embodiments of this application, and will not be repeated here.

[0107] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0108] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0110] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0113] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for accessing a legacy system, characterized in that, include: In response to a legacy system access request sent by a user, the system determines whether the user is already logged in to the target legacy system, wherein the legacy system access request is used to access the target legacy system. If the user is not logged in to the target legacy system, the system sends a legacy system login request corresponding to the user to the target legacy system, and receives the user information corresponding to the user returned by the target legacy system if the user successfully logs in to the target legacy system. If the user is already logged in to the target legacy system, the system reads the user information corresponding to the user from the cache. Based on the user information, the legacy system access request is rewritten to generate a target access request to the target legacy system. The target access request is then sent to the target legacy system.

2. The method as described in claim 1, characterized in that, Before determining whether the user is logged in to the target legacy system in response to a legacy system access request sent by the user, the method further includes: obtaining the access request sent by the user, wherein the access request includes a request path and a request header; and determining that the access request is the legacy system access request if the request path of the access request includes a first preset field and the request header of the access request includes a second preset field.

3. The method as described in claim 1, characterized in that, The legacy system access request includes a request header. Determining whether the user is logged in to the target legacy system includes: parsing the request header of the legacy system access request to determine the user's user identifier; constructing a unique session key corresponding to the user based on the user identifier; querying whether the cache contains a session corresponding to the unique session key; if the cache contains a session corresponding to the unique session key, determining that the user is logged in to the target legacy system; if the cache does not contain a session corresponding to the unique session key, determining that the user is not logged in to the target legacy system.

4. The method as described in claim 3, characterized in that, After successfully logging into the target legacy system and receiving the user information corresponding to the user returned by the target legacy system, the method further includes: establishing a session corresponding to the unique session key in the cache; and storing the user information in the session.

5. The method as described in any one of claims 3-4, characterized in that, The step of sending a legacy system login request corresponding to the user to the target legacy system and receiving the user information corresponding to the user returned by the target legacy system upon successful login includes: generating a legacy system login request corresponding to the user based on the user identifier; sending the legacy system login request to the target legacy system; and receiving the user information corresponding to the user returned by the target legacy system upon successful login.

6. The method according to any one of claims 1-4, characterized in that, The legacy system access request includes a request path and a request header. The step of rewriting the legacy system access request based on the user information to generate a target access request for the target legacy system includes: modifying the request path of the legacy system access request according to the access rules of the target legacy system; modifying the request header of the legacy system access request according to the user information and the access rules; and determining the modified legacy system access request as the target access request.

7. An access device for a legacy system, characterized in that, include: A first determining module is used to determine whether the user is logged in to the target legacy system in response to a legacy system access request sent by the user, wherein the legacy system access request is used to access the target legacy system; a receiving module is used to send a legacy system login request corresponding to the user to the target legacy system when the user is not logged in to the target legacy system, and to receive the user information corresponding to the user returned by the target legacy system if the user successfully logs in to the target legacy system; a reading module is used to read the user information corresponding to the user from a cache when the user is logged in to the target legacy system; a generating module is used to rewrite the legacy system access request according to the user information to generate a target access request to the target legacy system; and a sending module is used to send the target access request to the target legacy system.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the electronic device to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by an electronic device, it implements the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-6.

Images