Cross-site access processing method

Abstract

The embodiment of the invention provides a cross-site access processing method, which is applied to a first site side and comprises the following steps: establishing a long connection communication channel with a second site; intercepting a resource access request initiated by a first site page, generating a proxy request based on the resource access request when it is confirmed that the resource access request meets a preset cross-site access rule, and sending the proxy request carrying request identification information to a second site through a long connection communication channel; proxy response information is received through the long connection communication channel, and resource response data in the proxy response information is acquired; and generating a response result according to the proxy response information and the resource response data, and returning the response result to the first site. According to the method and the device, cross-site resource access and result return are realized, and the controllability, the flexibility and the expansion capability of cross-site resource access are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for handling cross-site access. Background Technology

[0002] In modern web application architectures, pages often need to access scripts, styles, API data, and media resources provided by multiple sites simultaneously. Cross-site resource access has become a common requirement in front-end development. On the one hand, architectural patterns such as front-end / back-end separation, microservices, and content delivery networks result in interfaces and static resources related to the same business function being deployed across different domains, ports, or paths. This requires browsers to interact with services from multiple different origins within the same page.

[0003] In existing technologies, a common approach to enabling cross-site resource access involves the server configuring cross-origin resource sharing (CRBS) fields in the response message. By explicitly declaring allowed origins, request headers, and methods in the response headers, browsers can relax same-origin restrictions on specific resources, provided the agreement is followed. However, relying on the target site to pre-configure allowed origins, request headers, and methods in the response headers means that once deployed, the front-end pages cannot adjust which sites and resources can be accessed based on changes in business scenarios during runtime, nor can these access permissions be flexibly reused or transferred between different pages.

[0004] It is evident that although the browser is the direct entity that initiates and consumes resource access requests, it lacks the ability to actively control cross-site resource access behavior at runtime, making it difficult to flexibly organize cross-site resource access relationships between sites in a way that is controlled by the front end. Summary of the Invention

[0005] This application provides a cross-site access processing method to achieve the effect of the current site being able to controllably access resources of other sites on the browser side.

[0006] In a first aspect, embodiments of this application provide a cross-site access processing method, applied to a first site, comprising:

[0007] Establish a long-term communication channel with the second site according to the preset connection establishment rules;

[0008] The resource access request initiated by the first site page is intercepted, and when it is confirmed that the resource access request meets the preset cross-site access rules, the resource access request is determined to be a proxy request.

[0009] A proxy request is generated based on the resource access request, and the proxy request carrying the request identification information is sent to the second site through the long connection communication channel;

[0010] At least one agent response information is received through the long connection communication channel, and resource response data in the agent response information is acquired;

[0011] According to the at least one agent response information and the resource response data, a response result is generated, and the response result is returned to the first site page, and cross-site access is completed.

[0012] In a possible implementation, the long connection communication channel with the second site is established according to the preset connection establishment rule, including:

[0013] Based on the initialization of the first site page, connection request information is generated according to the first site identifier and authentication information of the first site page;

[0014] The connection request information is sent to the second site;

[0015] After receiving the connection confirmation data returned by the second site and completing the handshake process based on the authentication information, the long connection communication channel with the second site is established.

[0016] In a possible implementation, the resource access request is confirmed to satisfy the preset cross-site access rule, including:

[0017] The resource access request initiated by the first site page is listened to, and a second site identifier is acquired according to a resource access parameter in the resource access request;

[0018] The first site identifier corresponding to the first site page is acquired;

[0019] When it is detected that the second site identifier is different from the first site identifier, and / or when it is detected that the transmission protocol used by the first site page is different from the transmission protocol corresponding to the resource access parameter, it is confirmed that the resource access request satisfies the preset cross-site access rule.

[0020] In a possible implementation, the agent request is generated based on the resource access request, and the agent request carrying request identifier information is sent to the second site through the long connection communication channel, including:

[0021] Request identifier information of the agent request is generated based on a random number, time information and / or a local counter,

[0022] According to a target resource address, an access mode, request header information and / or request body data in the resource access parameter, an agent request corresponding to the second site is constructed;

[0023] A verification identifier is added to the proxy request, wherein the verification identifier is calculated based on a preset key and the content of the proxy request;

[0024] The proxy request, carrying the verification identifier and the request identifier information, is sent to the second site through the long connection communication channel, so that the second site can verify the proxy request when it receives it.

[0025] The correspondence between the request identifier information and the proxy request is recorded in the local request mapping relationship set.

[0026] In one possible implementation, after receiving at least one proxy response message through the long-connection communication channel, the method further includes:

[0027] Extract request identification information from each of the proxy response messages, and determine the proxy request corresponding to the request identification information based on the local request mapping relationship set;

[0028] Extract resource response data from each of the proxy response messages, and when the proxy response message carries complete resource response data, store the resource response data as complete resource response data associated with the proxy request;

[0029] Alternatively, when the proxy response information carries fragmented resource response data, the resource response data carried in each of the proxy response information can be stored as partial resource response data associated with the proxy request.

[0030] In one possible implementation, obtaining the resource response data from the proxy response information includes:

[0031] Receive multiple proxy response messages carrying the same request identifier information, and obtain the fragment identifier carried in each proxy response message;

[0032] Based on the fragment identifier, the proxy response information is sorted and cached.

[0033] When the proxy response information is detected to carry an end identifier, multiple resource response data corresponding to the same request identifier information are concatenated to obtain complete resource response data, and the cached data corresponding to the request identifier information is deleted.

[0034] In one possible implementation, generating a response result based on the at least one proxy response message and the resource response data includes:

[0035] Based on the proxy request, obtain the response status information and response header information;

[0036] The resource response data is combined with the response status information and the response header information to generate a response result corresponding to the resource access interface of the first site page.

[0037] Secondly, embodiments of this application provide a cross-site access processing method, applied to a second site, comprising:

[0038] The proxy request sent by the first site page is received through a long-connection communication channel; wherein the proxy request carries request identification information and resource access parameters.

[0039] The proxy request is verified based on the authentication information and access control information carried in the proxy request;

[0040] If the proxy request passes the verification, a local resource access operation is initiated based on the resource access parameters to obtain the resource response data corresponding to the proxy request.

[0041] Based on the request identification information and the resource response data, at least one proxy response message is constructed and sent to the first site through the long connection communication channel.

[0042] In one possible implementation, verifying the proxy request based on the authentication information and access control information carried in the proxy request includes:

[0043] Extract token information and verification identifier from the proxy request;

[0044] The verification result is calculated based on the preset key and the content of the proxy request, and the verification result is compared with the verification identifier to obtain the integrity verification result of the proxy request;

[0045] Based on the token information, determine the set of allowed access resource addresses corresponding to the token information in the preset permission configuration;

[0046] The target resource address is parsed from the resource access parameters, and the target resource address is matched with the set of allowed access resource addresses to obtain the permission verification result of the proxy request;

[0047] If the integrity verification result of the proxy request is passed and the permission verification result is passed, the proxy request is determined to be a proxy request that has passed the verification.

[0048] In one possible implementation, constructing at least one proxy response message based on the request identification information and the resource response data, and sending the proxy response message to the first site page through the long-connection communication channel includes:

[0049] When the amount of the resource response data is detected to be greater than a preset data volume threshold, the resource response data is divided into multiple data fragments, and a fragment identifier is assigned to each data fragment.

[0050] Each of the proxy response messages carries the request identification information, the corresponding data fragment, and the fragment identifier, and at least one of the proxy response messages carries an end identifier;

[0051] The proxy response information is sent sequentially through the long connection communication channel so that the first site page can reassemble the resource response data according to the request identifier information, the fragment identifier and the end identifier.

[0052] Thirdly, embodiments of this application provide a cross-site access processing apparatus, applied to a first site side, comprising:

[0053] The channel establishment module is used to establish a long-term communication channel with the second station according to preset connection establishment rules;

[0054] The request processing module is used to intercept resource access requests initiated by the first site page, and when it is confirmed that the resource access request meets the preset cross-site access rules, it determines that the resource access request is a proxy request.

[0055] The request processing module is also used to generate a proxy request based on the resource access request, and send the proxy request carrying request identification information to the second site through the long connection communication channel;

[0056] The data receiving module is used to receive at least one proxy response message through the long connection communication channel and obtain resource response data from the proxy response message;

[0057] The result response module is used to generate a response result based on the at least one proxy response information and the resource response data, and return the response result to the first site page to complete cross-site access.

[0058] Fourthly, embodiments of this application provide a cross-site access processing apparatus, applied to a second site, comprising:

[0059] The request receiving module is used to receive a proxy request sent by the first site page through a long-connection communication channel; wherein the proxy request carries request identification information and resource access parameters;

[0060] The information verification module is used to verify the proxy request based on the authentication information and access control information carried in the proxy request;

[0061] The information verification module is also used to initiate a local resource access operation based on the resource access parameters and obtain resource response data corresponding to the proxy request if the proxy request passes verification.

[0062] The data construction module is used to construct at least one proxy response message based on the request identification information and the resource response data, and send the proxy response message to the first site through the long connection communication channel.

[0063] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0064] The memory stores computer-executed instructions;

[0065] The processor executes computer execution instructions stored in the memory, causing the processor to perform various possible implementations of any of the above methods.

[0066] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement various possible implementations of any of the methods described above.

[0067] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements various possible implementations of any of the methods described above.

[0068] This application provides a cross-site access processing method that establishes a long-term connection communication channel with a second site according to preset connection establishment rules, forming a continuously available bidirectional data channel between the two sites and providing a stable transmission foundation for subsequent multiple proxy accesses. By intercepting resource access requests initiated by the first site's page and only identifying them as proxy requests if they meet the preset cross-site access rules, centralized control over the scope of cross-site access is achieved, reducing the incorrect proxying of non-cross-site requests and thus improving the security and controllability of the access process. Furthermore, by generating a proxy request carrying request identification information based on the resource access request... The system processes requests and sends them to the second site, ensuring that each cross-site access has a clear identifier, thus enabling the request to be traceable and matchable during cross-site transmission. By receiving at least one proxy response message on a long-connection communication channel and obtaining the resource response data within it, and then generating a response result based on the proxy response message and resource response data and returning it to the first site page, the resources obtained across sites are compatible with the local resource access interface. This achieves transparent access to cross-site resources and result return without relying on server-side cross-origin configuration or traditional relay proxies, improving the front-end's controllability, flexibility, and scalability for cross-site resource access. Attached Figure Description

[0069] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0070] Figure 1 This is a schematic diagram of the application architecture for cross-site access provided in the embodiments of this application;

[0071] Figure 2 Flowchart of the cross-site access handling method provided in the embodiments of this application Figure One ;

[0072] Figure 3 This is a schematic flowchart of a method for processing proxy response information provided in an embodiment of this application;

[0073] Figure 4 Flowchart of the cross-site access handling method provided in the embodiments of this application Figure Two ;

[0074] Figure 5 Schematic diagram of the cross-site access processing device provided in the embodiments of this application Figure One ;

[0075] Figure 6 Schematic diagram of the cross-site access processing device provided in the embodiments of this application Figure Two ;

[0076] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0077] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0078] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0079] Figure 1This is a schematic diagram of the application architecture for cross-site access provided in this application embodiment, including a terminal device 101 where a first site page is located and a computer device 102 where a second site is located, which are interconnected. A browser program runs on the terminal device 101. The first site page loaded in the browser acts as the initiator of the cross-site access. A service worker thread for intercepting resource access requests is registered in the browser environment of this page, and the service worker thread executes the cross-site access processing logic on the first site side. A second site is deployed on the computer device 102. The second site establishes a long-connection communication channel with the terminal device 101 to receive proxy requests sent from the first site page and execute corresponding local resource access operations, thereby realizing cross-site access processing to the second site and its backend resources.

[0080] To address the issues that existing cross-site access (CSA) solutions generally rely on server-side configuration, lack proactive and fine-grained control of CSA resource access policies on the browser side, and struggle to enable access to resources from a first site without modifying individual business servers, this invention proposes the following: Within the browser environment, centered on the first site, a persistent communication channel is established between the first and second sites by defining connection rules, enabling continuous bidirectional data transmission between the two sites. During the operation of the first site page, resource access requests initiated by the first site page are uniformly intercepted, and based on preset CSA rules, these requests are determined to be within the scope of cross-site access required. Only resource access requests that meet the CSA rules are allowed to proceed. The system identifies resource access requests as proxy requests, enabling policy control over the scope of cross-site access on the front end. For resource access requests identified as proxy requests, a proxy request carrying request identification information is generated based on the original resource access request and sent to the second site through a long-connection communication channel, ensuring that each cross-site access has a unique identifier during transmission. After processing the proxy request, the second site returns at least one proxy response message containing resource response data to the first site through the same long-connection communication channel. The first site generates a response result compatible with the local resource access interface based on the received proxy response message and the resource response data therein and returns it to the first site page. Thus, without relying on the target resource server to enable Cross-Origin Resource Sharing (CORS), the first site completes cross-site access to the resources of the second site and returns the result, realizing a policy-controllable cross-site resource access mechanism for the front end.

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

[0082] Figure 2 Flowchart of the cross-site access handling method provided in the embodiments of this application Figure One Applied to the first site side, such as Figure 2 As shown, the method includes:

[0083] S21, establish a long-term connection communication channel with the second station according to the preset connection establishment rules.

[0084] In this embodiment, a long-lived communication channel refers to a communication path established between the first and second sites that can remain valid for a relatively long period of time. Once established, this communication path can be reused to carry multiple proxy requests and responses without requiring a separate connection creation and release for each resource access request. Predefined connection establishment rules specify which second sites to establish long-lived connections with, under what conditions to attempt to establish or restore long-lived connections, and the security and stability requirements to be followed during connection creation.

[0085] For example, the first site can comprehensively judge parameters such as the address information of the second site, the target site identifier, the transmission protocol type, and the connection hold duration based on preset connection establishment rules to determine whether to establish a long-term connection communication channel with the second site. When it is determined that a long-term connection communication channel needs to be established, the first site completes the connection establishment with the second site according to the process in the connection establishment rules, so that the first site can obtain a continuous communication channel to the second site in the browser environment.

[0086] Furthermore, after the long-connection communication channel is established, the first site can periodically monitor and maintain its status according to the connection establishment rules. When a connection anomaly is detected or the idle time exceeds a set threshold, a corresponding reconstruction or release strategy is triggered to keep the long-connection communication channel available. By setting preset connection establishment rules on the first site and establishing a long-connection communication channel with the second site accordingly, the front-end controllability and continuous reuse of the communication path during cross-site access processing are achieved. This provides a stable foundation for sending proxy requests and receiving proxy response information on this channel, reduces the latency overhead caused by frequently creating short connections, and lays the foundation for efficient cross-site resource access.

[0087] S22, intercept the resource access request initiated by the first site page, and determine that the resource access request is a proxy request when it is confirmed that the resource access request meets the preset cross-site access rules.

[0088] In this embodiment, the resource access request is an access instruction initiated by the page runtime environment of the first site page when it is normally loading scripts, style files, media files, or accessing backend service interfaces. This access instruction typically carries the address information of the target resource, the access method, and additional parameters related to the access. By setting up interception on the first site side, the request can be checked and processed before it is sent by the browser, providing an entry point for subsequent cross-site forwarding and local processing.

[0089] Predefined cross-site access rules describe the conditions under which a resource access request is considered a request requiring cross-site processing. These rules are configured on the first site side and reused during operation. The predefined cross-site access rules comprehensively consider factors such as the target site information, transport protocol type, and path characteristics of the target resource carried in the resource access request to distinguish between requests belonging to the same site and requests requiring access through a second site. When a resource access request meets the predefined cross-site access rules, it indicates that the request meets the triggering conditions for cross-site access, and in this case, the resource access request is marked as a proxy request.

[0090] By intercepting resource access requests and judging based on preset cross-site access rules, front-end control over the triggering conditions of cross-site access is achieved on the first site side. By filtering resource access requests before they are sent, only requests that meet the cross-site access rules are converted into proxy requests and included in the cross-site access processing flow, fine-grained control over the scope of cross-site access is achieved, which helps to improve the security and controllability of cross-site resource access.

[0091] S23, Generate a proxy request based on the resource access request, and send the proxy request carrying the request identification information to the second site through a long connection communication channel.

[0092] In this embodiment, the proxy request is a request object formed by processing and encapsulating the original resource access request. This proxy request at least contains information related to the target resource access extracted from the resource access request, used to trigger the corresponding resource access operation on the second site side. During the generation of the proxy request, the first site side carries corresponding request identification information to identify the uniqueness of the proxy request throughout the entire cross-site access process, so that the proxy response information can be associated and processed subsequently on the first site side.

[0093] After the proxy request is generated, the first site uses the established long-lived connection communication channel to send the proxy request carrying request identification information to the second site. Since the long-lived connection communication channel has been established and remains available, multiple proxy requests can be sent continuously on the same channel, reducing latency and connection overhead in cross-site access. By transmitting proxy requests carrying request identification information through the long-lived connection communication channel, the second site can accurately identify each proxy request at the receiving end and perform corresponding local resource access operations accordingly, laying the foundation for subsequently returning resource response data corresponding to the proxy request. This achieves centralized processing and identification management of request information during cross-site access, giving cross-site resource access traceable, distinguishable, and reusable channels in the browser environment, improving the flexibility and transmission efficiency of cross-site access.

[0094] S24, receive at least one proxy response message through the long connection communication channel, and obtain the resource response data in the proxy response message.

[0095] In this embodiment, the proxy response information is a response message returned by the second site to the first site via a long-connection communication channel after completing the local resource access operation. It carries the resource access result corresponding to the previous proxy request. The resource response data carries the specific resource content or interface return data, which can be text data, structured data, file content, or media data, etc. The first site continuously listens for proxy response information from the second site on the long-connection communication channel. When it detects the arrival of proxy response information, it parses the information and extracts the resource response data to subsequently generate a response result that matches the resource access interface of the first site's page.

[0096] With a long-connection communication channel established and maintained, the second site can send the corresponding proxy response information to the first site after completing one or more local resource access operations. The first site receives at least one proxy response information through the same long-connection communication channel, allowing multiple cross-site access processes to reuse a unified communication path without establishing a separate connection for each response. By centrally receiving proxy response information and extracting resource response data from it on the long-connection communication channel, the returned data during the cross-site access process can be uniformly received and managed in the browser environment. This ensures logical continuity with the aforementioned proxy requests and provides a data foundation for generating response results that can be directly used by the first site's page based on the resource response data. This achieves an orderly backflow of cross-site resource access results from the second site to the first site's page, which is beneficial for completing a complete request and response loop without modifying the server-side cross-domain configuration.

[0097] S25: Generate a response result based on at least one proxy response message and resource response data, and return the response result to the first site page to complete cross-site access.

[0098] In this embodiment, the first site performs unified processing and encapsulation of these resource response data within the browser environment, transforming them into response results that the original resource access interface of the first site page can directly recognize and consume. The response result is the return object that the first site page expects to receive when it normally initiates a resource access request. Its format is consistent with the existing resource access mechanism of the first site page, so that the first site page does not need to be aware of the process by which cross-site access is relayed through proxy requests and proxy response information at the underlying level.

[0099] During the response generation process, the first site can adapt the resource response data based on context information related to the proxy request, ensuring that the generated response is compatible with the existing resource processing logic of the first site page in terms of structure, encoding format, or parsing method. For example, when the first site page initiates a request through a standard resource access interface provided by the browser, the response can be constructed into the return object type agreed upon by that interface, allowing the page script to process the result in the same way as same-origin access. By processing the resource response data returned from the second site into a response that the first site page can directly use, and then returning the encapsulated response to the first site page that triggered the original resource access request, cross-site access becomes transparent on the page side, enabling the first site page to obtain resource content from the second site without modifying its existing business logic.

[0100] In this way, the cross-site access handling method completes the transformation from proxy response information and resource response data to response results on the first site side, and returns the response results to the first site page, forming a complete closed loop from resource access request interception, proxy request sending, proxy response information reception to result return. This ensures both the availability and consistency of cross-site resource acquisition, and reduces the dependence on server-side cross-domain configuration and additional relay components.

[0101] In one embodiment, step S21 is implemented as follows. Based on the above embodiment, a long-term connection communication channel with the second station is established according to preset connection establishment rules, including:

[0102] S211, Based on the initialization of the first site page, generate connection request information according to the first site identifier and authentication information of the first site page;

[0103] S212, send the connection request information to the second station;

[0104] S213: After receiving the connection confirmation data returned by the second station and completing the handshake process based on the authentication information, a long-term connection communication channel is established with the second station.

[0105] In this embodiment, when the first site page is loaded in the browser and enters the initialization phase, the first site identifier and preset authentication information corresponding to the first site page are first obtained. The first site identifier can be used to uniquely identify the site source to which the current first site page belongs, for example, it can be represented by a combination of domain name information, port information, and protocol type. The authentication information is used to indicate the identity and authorization status of the first site page to the second site, and can include tokens, signature data, timestamps, and authorization credentials issued by the backend system. Based on the above first site identifier and authentication information, the first site generates connection request information during the page initialization phase, so that the connection request information carries both an identifier field identifying the current first site source and an authentication field used for security verification, thereby providing context information and a security foundation for establishing a long-term communication channel with the second site.

[0106] After generating the connection request information, the first site sends it to the second site, where the second site parses and verifies the first site's identifier and authentication information contained within. After processing the connection request information, the second site returns connection confirmation data to the first site. This confirmation data may carry status information indicating the connection establishment result, as well as negotiation parameters related to subsequent communication. Upon receiving the connection confirmation data from the second site, the first site completes a handshake process based on the authentication information. This handshake process may include verification of the authentication information, confirmation of session parameter consistency, and binding of identifiers required for subsequent communication. When the handshake is complete, the long-lived communication channel between the first and second sites is considered successfully established. The first site then associates this long-lived communication channel with its current page for carrying proxy requests and responses. In summary, by generating connection request information based on the first site's identifier and authentication information during the initialization phase of the first site page, and completing connection confirmation and handshake processing with the second site, a long-term connection communication channel that meets the preset security policy and identity verification requirements is established. This achieves the pre-preparation and secure establishment of the communication path before cross-site access, reducing the latency and resource overhead caused by repeated handshakes and authentication during subsequent cross-site access.

[0107] In one embodiment, the confirmation in step S22 that the resource access request meets the preset cross-site access rules will be further explained here. Based on the above embodiment, it includes:

[0108] S221, listen for resource access requests initiated by the first site page, and obtain the second site identifier based on the resource access parameters in the resource access request;

[0109] S222, Obtain the first site identifier corresponding to the first site page;

[0110] S223, if it is detected that the second site identifier is different from the first site identifier, and / or if it is detected that the transmission protocol used by the first site page is different from the transmission protocol corresponding to the resource access parameters, then it is confirmed that the resource access request meets the preset cross-site access rules.

[0111] In this embodiment, by listening to resource access requests initiated by the first website page, various network requests to be sent are uniformly monitored and filtered. A resource access request refers to a network access action triggered by the first website page during its operation to obtain script files, style files, interface data, or media content, etc. The resource access parameters carried in the resource access request are used to characterize the target resource and its access method. Resource access parameters may include at least one of the following: target resource address, access method, request header information, and / or request body data, wherein the target resource address typically contains the address information and path information of the target website. By listening to resource access requests and parsing the resource access parameters within them, the first website can obtain information related to the target access object in advance before the resource access request is sent out of the browser.

[0112] Based on the parsing of resource access parameters, the first site can extract a second site identifier from the target resource address to identify the target site. The second site identifier characterizes the site origin of the target resource; for example, it can be composed of at least one of domain name information, port information, and protocol type, logically distinguishing different site environments. Simultaneously, the first site can also obtain a first site identifier corresponding to the current loading environment of the first site page. This first site identifier represents the site information to which the first site page itself belongs, maintaining the same identifier granularity and structure as the second site identifier, allowing for direct comparison between the two. By obtaining the second site identifier and the first site identifier from the resource access parameters and the first site page environment respectively, basic data is provided for subsequent determination of whether cross-site access occurs based on site differences.

[0113] After obtaining the second site identifier and the first site identifier, the first site side makes a comprehensive judgment based on the preset cross-site access rules, considering whether the two are the same and related transmission protocol information. When the second site identifier is detected to be different from the first site identifier, it can be considered that the target resource of the resource access request does not belong to the same site environment as the first site page, constituting a cross-site access. Simultaneously, the transmission protocol used by the first site page can be compared with the transmission protocol corresponding to the resource access parameters. If they are found to be different, it indicates that the resource access request involves a protocol-level crossing; for example, the first site page is in one transmission protocol environment, while the target resource address uses a different transmission protocol. The preset cross-site access rules can stipulate that as long as the second site identifier is different from the first site identifier, and / or the transmission protocol used by the first site page is different from the transmission protocol corresponding to the resource access parameters, the resource access request is identified as a cross-site access object.

[0114] This method of judgment allows for accurate confirmation of whether a resource access request meets preset cross-site access rules based on differences in site identifiers and transport protocols, at the stage when the first site page initiates the request. Requests that meet the conditions are then marked as proxy requests requiring retransmission through a second site. By jointly judging site identifiers and transport protocols, accurate identification of the scope of cross-site access is achieved, making the triggering conditions for cross-site access configurable and controllable on the first site side. This provides a prerequisite guarantee for subsequently performing cross-site proxy processing only on requests that meet security and policy requirements.

[0115] Next, in one embodiment, a proxy request is generated based on the resource access request, and the proxy request carrying request identification information is sent to the second site through a long-connection communication channel, including:

[0116] S231, Based on random numbers, time information and / or local counters, generate request identification information for the proxy request;

[0117] S232, construct a proxy request corresponding to the second site based on the target resource address, access method, request header information and / or request body data in the resource access parameters;

[0118] S233, Add a verification identifier to the proxy request, wherein the verification identifier is calculated based on the preset key and the content of the proxy request;

[0119] S234, through a long-connection communication channel, a proxy request carrying verification and request information is sent to the second station so that the second station can verify the proxy request upon receiving it;

[0120] S235, record the correspondence between request identification information and proxy requests in the local request mapping relationship set.

[0121] In this embodiment, the first step is to generate corresponding request identification information for each proxy request. This request identification information uniquely identifies the proxy request throughout the entire lifecycle of cross-site access, enabling accurate matching when receiving proxy response information from the second site. To this end, the current proxy request can be encoded and combined based on random numbers, time information, and / or a local counter, ensuring that the generated request identification information does not conflict within the same first site page session. For example, the current time information can be concatenated with a monotonically increasing local counter, and a random number factor can be introduced to construct request identification information that possesses both temporal order and randomness. By generating request identification information for each proxy request, request level differentiation is achieved during cross-site access, providing a foundation for subsequent response association and state management.

[0122] After generating the request identification information, the first site needs to construct a proxy request corresponding to the second site based on the resource access parameters. The resource access parameters may include the target resource address, access method, request header information, and / or request body data. By organizing and encapsulating these parameters, a proxy request is formed for initiating local resource access operations on the second site. Optionally, the target resource address is used as the target access object in the proxy request, the access method is mapped to a type marker for local access operations, and fields related to authentication, session, and content type in the request header information and request body data are retained to restore the semantics of the original resource access request. By constructing a proxy request based on the resource access parameters, the second site, upon receiving the proxy request, can access the target resource according to local resource access rules without being aware of the internal implementation details of the first site's page.

[0123] To enhance security during cross-site access, the first site can add a verification identifier to the proxy request, building upon the existing proxy request structure. This identifier, calculated based on a preset key and the content of the proxy request, is used by the second site to verify the integrity and source trustworthiness of the proxy request. For example, the target resource address, access method, and some request parameters from the proxy request can be selected as inputs, and a verification value can be obtained through a preset hash operation using the preset key. This verification value is then appended to the proxy request as the verification identifier. When the second site receives the proxy request, it can recalculate the verification result using the same preset key and calculation rules, and compare it with the verification identifier carried in the proxy request to determine whether the proxy request has been tampered with during transmission. By setting a verification identifier calculated based on a preset key and content in the proxy request, integrity protection and basic identity authentication capabilities for cross-site proxy communication are achieved.

[0124] After constructing the proxy request and adding the verification identifier, the first site sends the proxy request, carrying the verification identifier and request identifier information, to the second site through the previously established long-connection communication channel. By transmitting the proxy request containing the request identifier and verification identifier through the long-connection communication channel, both the latency of the proxy request during transmission is controlled, and context information is provided for the subsequent verification and response construction on the second site side. Utilizing the long-connection communication channel, efficient transmission and state continuity are achieved during cross-site access.

[0125] Furthermore, to support the orderly management of multiple concurrent proxy requests and their corresponding proxy response information on the first site side, the first site side can also maintain the correspondence between request identification information and proxy requests locally, and record this correspondence in a local request mapping relationship set. The local request mapping relationship set is a mapping structure indexed by request identification information and storing proxy requests and their related context information, used to quickly locate the corresponding proxy request when proxy response information is returned. For example, the local request mapping relationship set can be implemented using a key-value mapping data structure, with request identification information as the key and basic information and current processing status of the proxy request as the value. By recording the correspondence between request identification information and proxy requests, the first site side can accurately match the response data with the original proxy request based on the request identification information when receiving proxy response information, ensuring a one-to-one correspondence between requests and responses during cross-site access.

[0126] In one embodiment, Figure 3 This is a flowchart illustrating a method for processing proxy response information provided in an embodiment of this application. Based on the above embodiment, after receiving at least one proxy response message through a long-connection communication channel, the method includes:

[0127] S31, extract request identification information from each proxy response information, and determine the proxy request corresponding to the request identification information based on the local request mapping relationship set;

[0128] S32, extract resource response data from each proxy response information, and when the proxy response information carries complete resource response data, store the resource response data as complete resource response data associated with the proxy request;

[0129] S33, when the proxy response information carries fragmented resource response data, the resource response data carried in each proxy response information is stored as part of the resource response data associated with the proxy request.

[0130] In this embodiment, each proxy response is first parsed to extract the request identifier information. Using this request identifier information, a search is performed in the previously established local request mapping set to quickly identify the proxy request corresponding to the request identifier information and the associated context state information. Since the local request mapping set has already associated and stored the request identifier information with the proxy request when generating the proxy request, this mapping structure enables a one-to-one correspondence between the proxy response information and the original proxy request. By associating the proxy response information with the proxy request based on the request identifier information, it ensures that even in scenarios with multiple concurrent proxy requests and response information, the first site can still accurately distinguish between different cross-site access sessions, reducing data confusion caused by response mismatches.

[0131] After associating proxy response information with proxy requests, the first site continues to extract resource response data from each proxy response message and performs differentiated processing based on the format of the resource response data within the proxy response message. When a proxy response message carries complete resource response data, the first site can directly store this resource response data as the complete resource response data associated with the corresponding proxy request, mark it as received response content, and update the status information in the local request mapping set so that the complete resource response data can be directly used when generating subsequent response results. In an optional implementation, a corresponding response data record can be maintained for each proxy request. When a proxy response message carrying complete resource response data is detected, the entire response data is written to the corresponding record, and the receiving status of the record is updated to the completed status so that it can immediately participate in the assembly and return of subsequent response results.

[0132] When the proxy response information carries fragmented resource response data, the first site stores the resource response data carried in each proxy response message as partial resource response data associated with the corresponding proxy request. In this case, a fragmented cache structure can be maintained locally for this proxy request. This cache aggregates multiple resource response data fragments according to the request identifier information and records information such as the number of fragments received, fragment identifiers, and reception progress. For example, the resource response data fragments carried in each proxy response message can be stored in the cache along with their corresponding fragment identifiers. This allows for the orderly concatenation of these partial resource response data to restore the complete resource response data when all fragments are detected as received. By storing proxy response information carrying complete resource response data and fragmented resource response data separately, the first site can be compatible with resource response data of different sizes and transmission strategies. This ensures accurate association with the proxy request, provides a reliable data foundation for generating subsequent response results, and improves the scalability and stability of large-volume resource transmission during cross-site access.

[0133] In one embodiment, based on the above embodiments, obtaining resource response data from the proxy response information includes:

[0134] S241, Receive multiple proxy response messages carrying the same request identifier information, and obtain the fragmentation identifier carried in each proxy response message;

[0135] S242, sort and cache the response information of each proxy according to the fragment identifier;

[0136] S243, when the proxy response information is detected to carry an end identifier, multiple resource response data corresponding to the same request identifier information are concatenated to obtain complete resource response data, and the cached data corresponding to the request identifier information is deleted.

[0137] In this embodiment, to support reliable transmission of large amounts of resource response data during cross-site access, when the second site returns resource response data in a fragmented manner, the first site can centrally process multiple proxy response messages carrying the same request identifier information to achieve orderly reassembly of the fragmented data. Specifically, when the first site continuously receives proxy response messages on the long-connection communication channel, if it detects that multiple proxy response messages carry the same request identifier information, it can group these proxy response messages into the response data set corresponding to the same proxy request, and obtain the fragment identifier used to identify the fragmentation order or position from each proxy response message. The fragment identifier is a mark used to distinguish different resource response data fragments, such as a sequence number starting from zero, an offset code with a fixed format, or other identifier forms that can characterize the order of fragmentation. By identifying proxy response messages carrying the same request identifier information and extracting the fragment identifiers from them during the receiving phase, fragmented data belonging to the same proxy request are classified, providing a basis for subsequent sorting and splicing.

[0138] After obtaining the fragment identifiers, the first site can sort each proxy response message according to the fragment identifiers and cache the sorted proxy response messages and the resource response data they carry in a local data structure. The caching can adopt a grouping management approach based on request identifier information, that is, maintaining an independent cache area for each request identifier to store all resource response data fragments corresponding to that request identifier. Optionally, each fragment identifier can be mapped and stored to its corresponding resource response data using the request identifier as the key, thus ensuring that even if the fragment arrival order is not completely consistent with the sending order, the correct fragment arrangement order can still be restored using the fragment identifiers. By sorting based on fragment identifiers and caching the sorting results locally, the first site can maintain the logical order and integrity of the resource response data in scenarios where fragments arrive asynchronously or out of order, laying the data organization foundation for the final reassembly of complete resource response data.

[0139] After sorting and caching proxy response information carrying the same request identifier, the first site can also monitor for proxy response information carrying an end identifier. The end identifier indicates that all resource response data fragments corresponding to the proxy request have been sent. When the first site detects a proxy response information carrying an end identifier, it considers that the resource response data fragments corresponding to the current request identifier have been received completely. Under this premise, the first site can read multiple resource response data fragments corresponding to the same request identifier from the cache and concatenate them sequentially according to the order determined by the aforementioned fragment identifiers to recover the complete resource response data. After completing the concatenation and generating the complete resource response data, the first site can delete the cached data corresponding to the request identifier to release the occupied local storage resources and mark the complete resource response data as valid data that can be used for subsequent response result generation. By triggering the concatenation and cache cleanup of resource response data based on the signaled end identifier, complete recovery of resource response data and timely reclamation of cache space are achieved in fragmented transmission scenarios. This ensures the reliability of cross-site access while controlling the resource consumption caused by the accumulation of fragmented data in the browser environment.

[0140] In one embodiment, step S25 is further described below. Based on the above embodiment, a response result is generated according to at least one proxy response message and resource response data, including:

[0141] S251, Based on the proxy request, obtain the response status information and response header information;

[0142] S252 combines the resource response data with the response status information and response header information to generate a response result corresponding to the resource access interface of the first site page.

[0143] In this embodiment, since the proxy request is constructed when intercepting the resource access request initiated by the first site page, the proxy request retains key information related to the original resource access request, such as the access method, the expected return type, and control parameters related to exception handling. The first site can determine the response status information and response header information that should be returned to the first site page for this cross-site access based on these access characteristics recorded in the proxy request and in conjunction with the processing status maintained during the cross-site access process. The response status information can be used to characterize the logical success, failure, or exception type of this cross-site access, and the response header information can be used to describe the content type, length information, caching control strategy, and other auxiliary information related to the resource access interface agreement of the first site page. For example, when the resource response data is received normally and no transmission exception is detected, the response status information can be set to indicate a successful access, and fields representing the data type and encoding method can be added to the response header information; when authentication failure or target resource access exception is detected during the cross-site access process, corresponding response status information and response header information can be constructed according to the error handling strategy recorded in the proxy request to prompt the first site page to handle exceptions in a unified manner.

[0144] After obtaining the response status information and response header information, the first site can encapsulate the response status information, response header information, and resource response data into a return structure agreed upon by the interface, based on the resource access interface type used by the first site page. This allows the first site page to parse and process the response result according to the existing logic of same-origin access when receiving the response result. For example, the response status information can be mapped to a status code format recognizable by the page script, the response header information can be converted into a set of key-value pairs, and the resource response data can be embedded as part of the payload data in a unified response object. This ensures that the first site page can directly use the result through existing callback functions or asynchronous processing flows after obtaining the response result, without being aware of the cross-site access relay process. By generating a response result compatible with the resource access interface of the first site page based on the proxy request on the first site side, the cross-site access is presented as a regular resource access process on the page. This achieves resource access from the second site without changing the existing business code of the first site page, and ensures the semantic and structural consistency of the cross-site access result.

[0145] In one embodiment, after the first site sends a proxy request carrying request identification information through a long-connection communication channel, the first site page also maintains a waiting queue and timing information corresponding to the local request mapping set for each proxy request. Specifically, when writing a proxy request into the local request mapping set, the sending time of the proxy request and a preset timeout threshold are recorded, and the incomplete proxy requests in the local request mapping set are periodically traversed through timed detection or timer callbacks. When it is detected that a proxy request has not received a proxy response carrying the same request identification information within the preset timeout period, the proxy request is considered to have timed out, the proxy request is removed from the local request mapping set, and a response result indicating a failure status is constructed and returned to the first site page that triggered the original resource access request. By actively generating an error response and terminating the waiting process in the corresponding queue in timeout scenarios, the stability and controllability of the overall cross-site access processing are improved.

[0146] Figure 4 Flowchart of the cross-site access handling method provided in the embodiments of this application Figure Two Applied to the second site side, such as Figure 4 As shown, the method includes:

[0147] S41, receive a proxy request sent by the first site page through a long connection communication channel; wherein the proxy request carries request identification information and resource access parameters.

[0148] In this embodiment, the second site continuously listens for messages from the first site through an established long-connection communication channel. When a proxy request sent through this long-connection communication channel is detected, the proxy request is parsed to obtain the request identification information and resource access parameters carried within it. By receiving and parsing the proxy request carrying the request identification information and resource access parameters on the second site side based on the long-connection communication channel, request access and information transmission from the first site to the second site side during cross-site access are realized, providing a data foundation for subsequent local resource access operations on the second site side.

[0149] S42, verify the proxy request based on the authentication information and access control information carried in the proxy request.

[0150] Specifically, authentication information is used to characterize the identity and session legitimacy of the first site page, while access control information describes the scope of resources accessible to the first site page and its permission constraints on the second site side. The second site side can perform legitimacy checks on the authentication information based on preset security policies, such as verifying whether the authentication information is valid and conforms to pre-configured identity rules. Simultaneously, it can combine access control information to determine whether the resource access requests pointed to in the proxy requests fall within the allowed resource range. By performing authentication and permission checks on proxy requests on the second site side, dual control over the credibility of the cross-site access request source and the compliance of the access scope is achieved, improving the security and controllability of the overall cross-site access process.

[0151] S43. If the proxy request passes the verification, then according to the resource access parameters, initiate a local resource access operation to obtain the resource response data corresponding to the proxy request.

[0152] Specifically, local resource access operations involve, within the runtime environment of the second site, invoking internal service interfaces, accessing locally stored resource files, or accessing internal services accessible only to the second site, based on the access requirements described in the resource access parameters. The target resource location information carried in the resource access parameters can be used to determine the target object for local access, and the access method carried in the resource access parameters can be used to distinguish different types of access behaviors, such as reading data, submitting data, or triggering specific operations. During the execution of local resource access operations, the second site can also adapt or preprocess the access results according to its own business logic to generate a data representation suitable for cross-site data transmission. By initiating resource access locally on the second site after successful verification, the cross-site access process can provide controlled resource output capabilities for proxy requests from the first site's pages while maintaining the internal resource access rules of the second site unchanged.

[0153] S44, based on the request identification information and resource response data, construct at least one proxy response message, and send the proxy response message to the first site through a long connection communication channel.

[0154] In this embodiment, the second site associates the request identifier information with the corresponding resource response data to ensure that when the first site page receives the proxy response information, it can accurately match the returned data with the previously sent proxy request based on the request identifier information. When the resource response data is small, a single proxy response message carrying the complete resource response data can be used for return; when the resource response data is large or needs to be sent in batches, multiple proxy response messages can be constructed to carry partial resource response data respectively. However, regardless of the method used, each proxy response message retains the request identifier information consistent with the original proxy request. The second site sends the constructed proxy response information sequentially or in batches through a long-connection communication channel, allowing the first site page to receive and reconstruct the complete resource response data within the same logical session. By constructing proxy response information based on the request identifier information and resource response data and transmitting it back through the long-connection communication channel, the cross-site access results are uniformly encapsulated and statefully returned on the second site, ensuring the matching relationship between requests and responses and the continuity of data transmission between the two sites during the cross-site access process.

[0155] In another embodiment, the second site can be deployed as a relay site to build a front-end relay network between multiple first site pages and multiple target resource servers. Specifically, the first site page establishes a connection with the second site through a long-connection communication channel (e.g., a long-connection communication channel based on a browser persistent connection protocol) as described above, generates a proxy request based on the resource access request, and sends the proxy request carrying request identification information to the second site. Unlike the case of direct communication with a single resource server, in this embodiment, after receiving proxy requests from multiple first site pages, the second site further selects the corresponding target resource address based on the resource access parameters carried in each proxy request, and can initiate a resource access operation locally or forward the proxy request to the downstream site corresponding to the target resource address to obtain resource response data. For example, the second site can be deployed as a public relay service. It does not directly store business resources itself, but after receiving a proxy request and completing authentication and access control, it converts the proxy request into a local access operation to the resource server of the third site, obtains the resource response data corresponding to the proxy request, and then constructs proxy response information based on the request identification information and returns it to the corresponding first site page.

[0156] In this front-end relay network scenario, multiple first-site pages can act as initiators of resource access, while multiple second-site or downstream sites can act as relay nodes or resource providers, depending on the actual deployment. By repeatedly applying the cross-site access processing method described above among different nodes, resource access requests and resource response data can be indirectly shared and forwarded between the first-site pages through the relay site. This approach eliminates the need for resource servers to configure cross-site access policies separately for each front-end site. The relay site centrally executes authentication, access control, and fragmentation forwarding logic, allowing cross-site access capabilities to be reused and orchestrated on demand across multiple sites. This constructs a front-end relay network supporting multi-site peer-to-peer collaboration without altering the original deployment structure of each business site, improving the flexibility and scalability of cross-site resource access.

[0157] In one embodiment, step S42 is further described below. Based on the above embodiment, it includes:

[0158] S421, Extract token information and verification identifier from the proxy request;

[0159] S422, Calculate the verification result based on the preset key and the content of the proxy request, and compare the verification result with the verification identifier to obtain the integrity verification result of the proxy request;

[0160] S423, Based on the token information, determine the set of allowed access resource addresses corresponding to the token information in the preset permission configuration;

[0161] S424, parse the target resource address from the resource access parameters, match the target resource address with the set of allowed access resource addresses, and obtain the permission verification result of the proxy request;

[0162] S425, if the integrity verification result of the proxy request is passed and the permission verification result is passed, the proxy request is determined to be a proxy request that has passed the verification.

[0163] In this embodiment, the token information is used to identify the identity and permission configuration of the first site page or the calling entity behind it on the second site side. It can typically consist of a pre-issued access token, session identifier, or other markers that can be used for permission lookup. The verification identifier, on the other hand, is verification data generated based on the content of the proxy request and a preset key when the proxy request is constructed on the first site side. It is used on the second site side to verify whether the content of the proxy request has been altered during transmission. By explicitly extracting the token information and verification identifier from the proxy request, input parameters are provided for subsequent integrity and permission verification.

[0164] After obtaining the verification identifier, the second site can calculate the verification result based on the preset key and the content of the proxy request, and compare this result with the verification identifier carried in the proxy request to obtain the integrity verification result of the proxy request. The preset key can be a key pre-configured on the second site and shared with the first site. The second site uses the same algorithm as the first site, taking the content within a specified range in the proxy request as input, and combines it with the preset key to generate a locally calculated verification result. When the locally calculated verification result matches the verification identifier carried in the proxy request, the integrity verification result of the proxy request can be determined as passed; if the two do not match, the integrity verification result can be determined as failed, thereby blocking further processing of the proxy request.

[0165] After completing the integrity verification, the second site also needs to verify the access permissions of the proxy request based on the token information and resource access parameters. The default permission configuration is a permission mapping relationship maintained on the second site, which is used to record the resource access range corresponding to different token information. For example, using the token information as an index, the allowed resource address prefix, resource category or interface set is associated and stored, thereby forming a granular access control policy.

[0166] Simultaneously, the second site can parse the target resource address from the resource access parameters. The target resource address represents the specific resource location that the proxy request seeks to access. Based on this information, the second site matches the target resource address with the set of allowed resource addresses determined by the token information to obtain the permission verification result of the proxy request. This ensures that even if the proxy request originates legitimately and its content has not been tampered with, access can only be granted to the pre-authorized resource range. When both the integrity verification result and the permission verification result of the proxy request pass, the second site determines the proxy request as a valid one and allows it to proceed to the subsequent resource access processing flow. By jointly determining the integrity and permission verification results, a comprehensive analysis of cross-site proxy requests is achieved in terms of both content security and access scope, improving the reliability of the entire cross-site access mechanism in terms of security and controllability.

[0167] In one embodiment, based on request identification information and resource response data, at least one proxy response message is constructed and sent to the first site via a long-connection communication channel, including:

[0168] S441, when the amount of resource response data detected is greater than the preset data amount threshold, the resource response data is divided into multiple data fragments and a fragment identifier is assigned to each data fragment;

[0169] S442, each proxy response message carries request identification information, corresponding data fragment and fragment identifier, and at least one proxy response message carries an end identifier;

[0170] S443, through a long connection communication channel, sequentially sends the response information of each proxy to the first site, so that the first site page can reassemble the resource response data according to the request identifier, fragment identifier and end identifier.

[0171] In this embodiment, when the amount of resource response data detected exceeds a preset data volume threshold, the second site divides the resource response data into multiple data fragments. The preset data volume threshold can be configured based on the bandwidth conditions of the long-connection communication channel, the processing capacity of the first site page, and the stability requirements of a single transmission in the target operating environment, to limit the maximum amount of data that can be appropriately carried in a single proxy response message. When dividing the resource response data, equal-length fragments or partially adjustable fragment lengths can be used to sequentially divide the original resource response data into several continuous data segments, and each data fragment is assigned a fragment identifier to identify the fragment order or position, such as an incrementing sequence number or a marker indicating an offset position. This processing helps improve the stability and fault tolerance of the cross-site transmission process.

[0172] After completing the fragmentation and fragment identifier allocation of the resource response data, the second site, when generating content for each proxy response message, includes the request identifier information corresponding to the current cross-site access session, the data fragment corresponding to the proxy response message, and a fragment identifier used to identify the order of the data fragments. This ensures that each proxy response message can be reliably assigned to the correct proxy request and its corresponding fragment position by the first site page. To facilitate the first site page in determining whether all resource response data has been sent, the second site can also include an end identifier in at least one proxy response message. The end identifier indicates that all data fragments of the resource response data corresponding to the current request identifier information have been constructed and are ready to be sent, or have already been sent along with this and previous proxy response messages.

[0173] Next, the second site sends each proxy response message sequentially through the established long-connection communication channel. By sending proxy response messages carrying request identifiers, fragment identifiers, and end identifiers sequentially from the second site, the first site page can stably reconstruct large-volume resource response data in cross-site access scenarios, achieving fragmented transmission and complete recovery of large files or long data streams, thus balancing transmission efficiency and data integrity in cross-site access.

[0174] In one embodiment, long-connection communication channels (such as WebSocket) can be implemented not only through bidirectional communication channels based on browser persistent connection protocols, but also through point-to-point data transmission mechanisms, such as long-connection communication channels based on browser peer-to-peer connection technology, or Web Real-Time Communication (WebRTC) data channels. In this embodiment, when the first site initializes its page, it first exchanges candidate address information, network capability information, and connection intent parameters with the second site through a signaling channel according to preset connection establishment rules. After completing candidate address collection and connectivity detection, a data transmission channel for carrying user data is established. This embodiment utilizes point-to-point data transmission mechanisms to establish long-connection communication channels between browsers or between a browser and a server. In some network environments, this can reduce the number of intermediate forwarding nodes, lower transmission latency in cross-site access, and provide an alternative underlying transmission method for proxy requests and proxy responses without changing the existing cross-site access processing flow, thus improving the flexibility of long-connection communication channel implementation.

[0175] Figure 5 Schematic diagram of the cross-site access processing device provided in the embodiments of this application Figure One Applied to the first site side, such as Figure 5 As shown, the cross-site access processing device provided in this embodiment includes:

[0176] The channel establishment module 501 is used to establish a long-term connection communication channel with the second station according to the preset connection establishment rules.

[0177] The request processing module 502 is used to intercept resource access requests initiated by the first site page, and determine that the resource access request is a proxy request when it is confirmed that the resource access request meets the preset cross-site access rules.

[0178] The request processing module 502 is also used to generate a proxy request based on the resource access request, and send the proxy request carrying the request identification information to the second site through a long connection communication channel;

[0179] The data receiving module 503 is used to receive at least one proxy response message through a long-connection communication channel and obtain the resource response data in the proxy response message;

[0180] The result response module 504 is used to generate a response result based on at least one proxy response information and resource response data, and return the response result to the first site page to complete cross-site access.

[0181] Figure 6 Schematic diagram of the cross-site access processing device provided in the embodiments of this applicationFigure Two Applied to the second site side, such as Figure 6 As shown, the cross-site access processing device provided in this embodiment includes:

[0182] The request receiving module 601 is used to receive a proxy request sent by the first site page through a long connection communication channel; wherein the proxy request carries request identification information and resource access parameters;

[0183] The information verification module 602 is used to verify the proxy request based on the authentication information and access control information carried in the proxy request;

[0184] The information verification module 602 is also used to initiate a local resource access operation based on the resource access parameters and obtain the resource response data corresponding to the proxy request if the proxy request is verified.

[0185] The data construction module 603 is used to construct at least one proxy response message based on the request identification information and resource response data, and send the proxy response message to the first site through a long connection communication channel.

[0186] The cross-site access processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0187] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0188] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0189] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0190] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0191] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0192] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0193] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0194] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for handling cross-site access, characterized in that, Applied to the first site side, the method includes: Establish a long-term communication channel with the second site according to the preset connection establishment rules; The resource access request initiated by the first site page is intercepted, and when it is confirmed that the resource access request meets the preset cross-site access rules, the resource access request is determined to be a proxy request. A proxy request is generated based on the resource access request, and the proxy request carrying the request identification information is sent to the second site through the long connection communication channel; Through the long-connection communication channel, at least one proxy response message is received, and resource response data in the proxy response message is obtained; Based on the at least one proxy response information and the resource response data, a response result is generated and returned to the first site page to complete cross-site access.

2. The method according to claim 1, characterized in that, The step of establishing a long-term connection communication channel with the second station according to preset connection establishment rules includes: Based on the initialization of the first site page, connection request information is generated according to the first site identifier and authentication information of the first site page; Send the connection request information to the second site; After receiving the connection confirmation data returned by the second site and completing the handshake process based on the authentication information, a long-term connection communication channel is established with the second site.

3. The method according to claim 1, characterized in that, The confirmation that the resource access request meets the preset cross-site access rules includes: Listen for resource access requests initiated by the first site page, and obtain the second site identifier based on the resource access parameters in the resource access request; Obtain the first site identifier corresponding to the first site page; If the second site identifier is detected to be different from the first site identifier, and / or if the transmission protocol used by the first site page is detected to be different from the transmission protocol corresponding to the resource access parameters, the resource access request is confirmed to meet the preset cross-site access rules.

4. The method according to claim 3, characterized in that, The step of generating a proxy request based on the resource access request and sending the proxy request carrying request identification information to the second site through the long-connection communication channel includes: Based on random numbers, time information, and / or a local counter, the request identification information of the proxy request is generated. Based on the target resource address, access method, request header information and / or request body data in the resource access parameters, construct a proxy request corresponding to the second site; A verification identifier is added to the proxy request, wherein the verification identifier is calculated based on a preset key and the content of the proxy request; The proxy request, carrying the verification identifier and the request identifier information, is sent to the second site through the long connection communication channel, so that the second site can verify the proxy request when it receives it. The correspondence between the request identifier information and the proxy request is recorded in the local request mapping relationship set.

5. The method according to claim 1, characterized in that, After receiving at least one proxy response message through the long-connection communication channel, the process further includes: Extract request identification information from each of the proxy response messages, and determine the proxy request corresponding to the request identification information based on the local request mapping relationship set; Extract resource response data from each of the proxy response messages, and when the proxy response message carries complete resource response data, store the resource response data as complete resource response data associated with the proxy request; Alternatively, when the proxy response information carries fragmented resource response data, the resource response data carried in each of the proxy response information can be stored as partial resource response data associated with the proxy request.

6. The method according to claim 5, characterized in that, Obtaining resource response data from the proxy response information includes: Receive multiple proxy response messages carrying the same request identifier information, and obtain the fragment identifier carried in each proxy response message; Based on the fragment identifier, the proxy response information is sorted and cached. When the proxy response information is detected to carry an end identifier, multiple resource response data corresponding to the same request identifier information are concatenated to obtain complete resource response data, and the cached data corresponding to the request identifier information is deleted.

7. The method according to claim 1, characterized in that, The step of generating a response result based on the at least one proxy response information and the resource response data includes: Based on the proxy request, obtain the response status information and response header information; The resource response data is combined with the response status information and the response header information to generate a response result corresponding to the resource access interface of the first site page.

8. A method for handling cross-site access, characterized in that, Applied to the second site side, including: The proxy request sent by the first site page is received through a long-connection communication channel; wherein the proxy request carries request identification information and resource access parameters. The proxy request is verified based on the authentication information and access control information carried in the proxy request; If the proxy request passes the verification, a local resource access operation is initiated based on the resource access parameters to obtain the resource response data corresponding to the proxy request. Based on the request identification information and the resource response data, at least one proxy response message is constructed and sent to the first site through the long connection communication channel.

9. The method according to claim 8, characterized in that, The step of verifying the proxy request based on the authentication information and access control information carried in the proxy request includes: Extract token information and verification identifier from the proxy request; The verification result is calculated based on the preset key and the content of the proxy request, and the verification result is compared with the verification identifier to obtain the integrity verification result of the proxy request; Based on the token information, determine the set of allowed access resource addresses corresponding to the token information in the preset permission configuration; The target resource address is parsed from the resource access parameters, and the target resource address is matched with the set of allowed access resource addresses to obtain the permission verification result of the proxy request; If the integrity verification result of the proxy request is passed and the permission verification result is passed, the proxy request is determined to be a proxy request that has passed the verification.

10. The method according to claim 9, characterized in that, The step of constructing at least one proxy response message based on the request identifier information and the resource response data, and sending the proxy response message to the first site page through the long connection communication channel, includes: When the amount of the resource response data is detected to be greater than a preset data volume threshold, the resource response data is divided into multiple data fragments, and a fragment identifier is assigned to each data fragment. Each of the proxy response messages carries the request identification information, the corresponding data fragment, and the fragment identifier, and at least one of the proxy response messages carries an end identifier; The proxy response information is sent sequentially through the long connection communication channel so that the first site page can reassemble the resource response data according to the request identifier information, the fragment identifier and the end identifier.

Images