USRE45139E1 - Method and apparatus for cross-domain communication using designated response processing page - Google Patents

Method and apparatus for cross-domain communication using designated response processing page Download PDF

Info

Publication number
USRE45139E1
USRE45139E1 US14/139,426 US201314139426A USRE45139E US RE45139 E1 USRE45139 E1 US RE45139E1 US 201314139426 A US201314139426 A US 201314139426A US RE45139 E USRE45139 E US RE45139E
Authority
US
United States
Prior art keywords
domain
request
data
page
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US14/139,426
Inventor
Zhanyuan Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to US14/139,426 priority Critical patent/USRE45139E1/en
Assigned to ALIBABA GROUP HOLDING LIMITED reassignment ALIBABA GROUP HOLDING LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LI, ZHANYUAN
Application granted granted Critical
Publication of USRE45139E1 publication Critical patent/USRE45139E1/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

Definitions

  • the present invention relates generally to the field of network technology and more particularly to method, system and device for cross-domain communication.
  • Existing browser software such as Internet Explorer or Firefox provides a security isolation mechanism based on network domains to prevent programs from different websites from accessing each other's data and causing visitor's private data to be misappropriated from one website to another.
  • Some large web platforms can include many different domain names or different websites that are in trust relationships with each other and often need to exchange data and service among different websites.
  • Another technique for cross-domain communication involves decreasing the client browser security setting to allow for cross-domain visits. Decreasing the security standard, however, makes the client more vulnerable to exploits by malicious web sites.
  • Another technique involves URL jumping between different websites, where one website requests a page in another domain and sends information in the form of URL parameters and the other domain returns information by redirecting the browser to the web page in the requester's domain and sending information in the form of URL parameters.
  • URL jumping is used to communicate between different websites, the servers must deal with greatly increased load and efficiency is decreased.
  • the technique also leads to security problems since the data information transferred via the URL is in plain view in the address bar of the browser. Further, the technique cannot transfer large amounts of data because of the limit on the URL length.
  • Another technique uses cross-domain scripting citation.
  • a web page in a domain uses the ⁇ script> label to reference Javascript (JS) file contents of another domain and transfers the data in the form of URL parameters.
  • the JS file of the other domain can compile script freely to send the data directly to the current web page.
  • This technique tends to be complex since new script needs to be generated in each communication. Further, the data of one domain would be completely exposed to the script of another and can be easily misappropriated.
  • FIG. 1 is a block diagram illustrating an embodiment of a system that supports cross-domain communication.
  • FIG. 2A is a flowchart illustrating an embodiment of a process for cross-domain communication.
  • FIG. 2B is a flowchart illustrating an embodiment of a process for cross-domain communication.
  • FIG. 3 is a flowchart illustrating another embodiment of a process for cross-domain communication.
  • FIG. 4 is a system diagram illustrating an embodiment of a cross-domain communication system.
  • FIG. 5 is a block diagram illustrating an embodiment of a sender device.
  • FIG. 6 is a block diagram illustrating an embodiment of a receiver device.
  • the invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor.
  • these implementations, or any other form that the invention may take, may be referred to as techniques.
  • the order of the steps of disclosed processes may be altered within the scope of the invention.
  • a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task.
  • the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
  • a domain refers to a collection of network devices organized under a common network name, such as www.example.com.
  • the techniques can be used for implementing safe communication among different domains while guaranteeing security isolation of domains with respect to browser software.
  • FIG. 1 is a block diagram illustrating an embodiment of a system that supports cross-domain communication.
  • system 100 includes a first domain 104 and a second domain 106 , which in this example are shown to be isv.com and alisoft.com, respectively.
  • domain 104 is presumed to be the domain from which a data request is sent and is referred to as the first domain or the sender domain
  • domain 106 is presumed to be the domain to which a data request is received and is referred to as the second domain or the receiver domain.
  • Communication in the reverse direction where domain 106 is the sender domain and domain 104 is the receiver domain is possible.
  • One or more servers are included in the domains to provide web services such as displaying web pages and responding to client requests.
  • different physical servers are included in different domains.
  • a physical server device is virtualized to operate as multiple virtual servers that separately service different domains.
  • domain 104 there are one or more web pages that can be accessed by client devices such as 102 via client software such as a web browser.
  • a designated response processing page also referred to as the ACK page
  • URL Universal Resource Locator
  • ASK page in this case with the URL of alisoft.com/ask.htm
  • ASK page is configured to handle cross-domain transfer requests from outside domains such as domain 104 . Details of the page configurations and operations are described below.
  • FIG. 2A is a flowchart illustrating an embodiment of a process for cross-domain communication.
  • Process 200 may be implemented on a device such as a server implementing services for domain 104 .
  • a data request is sent from the sender domain to the receiver domain.
  • the request may be evoked in response to a client action that is made on a webpage that is not specifically designated for cross-domain communication.
  • a webpage is referred to as an originating page.
  • the data request is sent to a designated request processing page in the receiver domain.
  • the designated request processing page is specifically configured to respond to cross-domain data request requests.
  • a response is received from the receiver domain. If the communication session is successful, the response would include requested data. The response is directed to a designated response processing page in the sender domain. The response is processed by the response processing page and information is passed to the originating page as appropriate.
  • the response is processed and can be passed on to the originating page as appropriate.
  • FIG. 2B is a flowchart illustrating an embodiment of a process for cross-domain communication.
  • Process 250 may be implemented on a device such as a server implementing services for domain 106 .
  • a data request from the sender domain is received in the receiver domain.
  • the data request is directed to a designated request processing page in the receiver domain.
  • the data request is processed.
  • Information relating to the response is gathered and a response is generated.
  • the response is sent to a designated response processing page in the sender domain to be processed and passed on to the originating page as appropriate.
  • the above cross-domain communication technique observes the security isolation mechanisms of browser domains, without requiring decreased browser security standards, URL page jumping, or substantially increased server load. It guarantees fair and symmetrical security protection for both sides for communication.
  • the server of the sender domain deploys a designated response processing page and the server of the receiver domain deploys a designated request processing page.
  • the browser opens the designated pages to transfer data for cross-domain communication.
  • deployment refers to placing these page files on the appropriate server and “open” refers to sending a request to a page file by a client browser.
  • the client browser loads the originating page, which is a page that initiates cross domain communication.
  • the originating page may be a login page for the sender domain that requires certain information from the receiver domain (e.g., user account in the receiver domain) to complete the login process in the sender domain.
  • the originating page locates the name of the sender domain, such as isv.com.
  • the browser that loaded the originating page will open a hidden page on the server in the sender domain, use the hidden page to open a an ASK page deployed on the server of the receiver domain and transfer the command and the data associated with the communication request using an a URL fragment identifier of the request and the name property of a window object of the page.
  • the receiver domain receives the request command and data at the designated request processing page, also referred to as the ASK page. Data pertaining to the response of the request is extracted. Since the ASK page is located in the receiver domain, such as alisoft.com, it can acquire related data in the domain according to the request that is received.
  • the ASK page opens the designated response processing page (i.e., the ACK page) on the sender domain or opens another hidden page and uses the hidden page to open the ACK page and sends the returning position and the response data using an a URL fragment identifier and the name property of a window object of the page. Since the ACK page is located in the sender domain, such as isv.com, it can return the response data to the originating page in the same domain.
  • the ASK page is used for receiving request command commands for cross-domain transfer and extracting response data according to the command commands.
  • the ACK page is used for receiving the response data sent by the ASK page and returning the response data to the originating page in the sender domain.
  • the sender and receiver domains only need to exchange data via their respective servers the first time a specific cross-domain communication is made. In subsequent cross-domain transfers, the browser will use its cache function to cache the parameters sent the first time and the receiver of communication extracts the resulting data from the browser directly when receiving a cross-domain transfer request.
  • FIG. 3 is a flowchart illustrating another embodiment of a process for cross-domain communication.
  • the servers on the sender and receiver domains deploy the designated response processing ACK page and the designated request processing ASK page, respectively.
  • Bi-direction communications can be achieved by each domain deploying both an ACK page and an ASK page.
  • the designated request processing ASK page is a static page in some embodiments and a dynamic page in some embodiments where additional Hypertext Transfer Protocol (HTTP) header information is added.
  • the response processing ACK page is a static page in some embodiments.
  • ASK pages and ACK pages are basic pages for communication between two domains. They are collectively referred to as communication pages.
  • the communication pages agree on the same request format and follow the same communication protocol.
  • the HTTP GET request can be used for a requesting page and command, and communication commands and data are not transferred as URL parameters.
  • opening the hidden page includes opening an invisible new window or an invisible iframe.
  • the hidden page opens the ASK page deployed on the server of the receiver domain and a request command and parameters are transferred.
  • the request command is transferred in the form of a fragment identifier attached to the URL and the data can be transferred in the form of the name property of a window object.
  • the fragment identifier is attached to the URL by appending a “#” identifier to the URL and appending a string to “#.”.
  • a fragment identifier can be used for locating a designated anchor node (reading position) in a page and is processed by the client rather than the server.
  • URLs with or without a fragment identifier or with different fragment identifiers are considered to be the same URL for the server and are cached the same way by the browser. Therefore, data is exchanged the first time the URL is requested and is cached in the browser and available for subsequent requests without requiring further data exchange between the servers and the browser.
  • the ASK page in the receiver domain implements corresponding service
  • the ASK page in the receiver domain opens a hidden new page or uses the ASK page itself to open the ACK page in the sender domain and transfers the response data to the ACK page in the sender domain.
  • the security isolation mechanism built into the browser forbids a program of a page in one domain to operate the content and data of another page directly. But when a page in one domain can open a page in another domain, transferring data to a page in the other domain is permitted in the form of a URL or the name property of a window object.
  • the ACK page in the original domain website returns the response data received to the originating page.
  • a typical response to the ASK page is as follows:
  • the ACK page and the originating page are located in the same domain, the ACK page can visit the originating page and thus transfer the resulting data to the originating page.
  • request and response data are transferred in the form of strings in JSON format.
  • JSON format is native data expression form for JavaScript language and has the advantages of simple form, compact format and convenient conversion. Data can be transferred by the name property of window object, by which large amount data amounts of data can be transferred. Data also can be transferred all by fragment identifiers.
  • the data above can be packaged into a series of JavaScript functions to developers.
  • function envoy domainName, serviceName, on Success, on Error
  • domainName is the domain name for communication
  • serviceName is the service name being requested
  • on Success indicates the return function upon success
  • on Error indicates the return function upon failure.
  • FIG. 4 is a system diagram illustrating an embodiment of a cross-domain communication system.
  • the system includes a sender device 100 410 and a receiver device 200 420 that belong to different domains.
  • the sender 100 410 is implemented in some embodiments as a server configured to send a request to the designated request processing page on the receiver 200 420 and to receive a response sent by the designated request processing page on the receiver, at a designated local response processing page on the sender.
  • the receiver 200 420 is implemented in some embodiments as a server configured to receive the request sent by the sender 100 410 via the designated request processing page, processing the request sent by the sender 100 410 and acquiring response data and sending the response to the response processing page on receiver 100 sender 410.
  • FIG. 5 is a block diagram illustrating an embodiment of a sender device.
  • the device includes a request sending module 10 , a response receiving module 20 and a data acquiring module 30 .
  • the request sending module 10 is configured to a request to the designated request processing page in the receiver. It further includes an originating page configured to send data such as the request command and associated data.
  • the response receiving module 20 is configured to process a response sent by the receiver. It further includes a designated response processing page configured to receive the response.
  • the data acquiring module 30 is configured to acquire the response from the page for receiving data in the sender.
  • FIG. 6 is a block diagram illustrating an embodiment of a receiver device for cross-domain communication.
  • the device in this example includes a request receiving module 40 , a processing module 50 and a response sending module 60 .
  • the request receiving module 40 is configured to receive a request from a sender. It further includes a designated request processing page configured to receive the request command and associated data.
  • the processing module 50 is configured to process the request sent by the sender and to acquire response data.
  • the response sending module 60 is used for sending the response to a designated response processing page on the sender.
  • a device may be configured both as a sender and a receiver and includes all the modules shown in FIGS. 5 and 6 .
  • the designated request processing page and the designated response processing page can be different pages or the same page.
  • the page(s) can be configured as dynamic pages or static pages.
  • the modules described above can be implemented as software components executing on one or more general purpose processors, as hardware such as programmable logic devices and/or Application Specific Integrated Circuits designed to perform certain functions or a combination thereof.
  • the modules can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as CD-ROM, U disk, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, network equipments, etc.) implement the methods described in the embodiments of the present invention.
  • the modules may be implemented on a single device or distributed across multiple devices. The functions of the modules may be merged into one another or further split into multiple sub-modules.
  • the technical personnel in this field can understand clearly that the present invention can be implemented by hardware or software and a necessary current hardware platform.
  • the technical program of the present invention can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as CD-ROM, U disk, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, or network equipments equipment, etc.) implement the methods described in the embodiments of the present invention.

Abstract

Cross-domain communication between a sender domain and a receiver domain includes: receiving, in the receiver domain, a data request from the sender domain, the data request being directed to a designated request processing page in the receiver domain; processing the data request to generate a response; and sending the response to the sender domain, the response being directed to a designated response processing page in the sender domain. Alternatively, cross-domain communication includes receiving, in the receiver domain, a data request from the sender domain, the data request being directed to a designated request processing page in the receiver domain; processing the data request to generate a response; and sending the response to the sender domain, the response being directed to a designated response processing page in the sender domain.

Description

This application claims priority to People's Republic of China Patent Application No. 200810147259.3 entitled METHOD, SYSTEM AND DEVICE FOR CROSS-DOMAIN COMMUNICATION filed Aug. 25, 2008 which is incorporated herein by reference for all purposes.
FIELD OF THE PRESENT INVENTION
The present invention relates generally to the field of network technology and more particularly to method, system and device for cross-domain communication.
BACKGROUND OF THE PRESENT INVENTION
Existing browser software such as Internet Explorer or Firefox provides a security isolation mechanism based on network domains to prevent programs from different websites from accessing each other's data and causing visitor's private data to be misappropriated from one website to another. Some large web platforms, however, can include many different domain names or different websites that are in trust relationships with each other and often need to exchange data and service among different websites.
Several techniques for cross-domain communication exist. Current techniques, however, usually have certain disadvantages.
One existing technique for cross-domain communication involves exploiting certain security holes in the browser. This is not secure since malicious websites can also use security vulnerabilities to launch attacks. Also, the technique becomes obsolete as soon as the security holes are patched.
Another technique for cross-domain communication involves decreasing the client browser security setting to allow for cross-domain visits. Decreasing the security standard, however, makes the client more vulnerable to exploits by malicious web sites.
Another technique involves URL jumping between different websites, where one website requests a page in another domain and sends information in the form of URL parameters and the other domain returns information by redirecting the browser to the web page in the requester's domain and sending information in the form of URL parameters. When URL jumping is used to communicate between different websites, the servers must deal with greatly increased load and efficiency is decreased. The technique also leads to security problems since the data information transferred via the URL is in plain view in the address bar of the browser. Further, the technique cannot transfer large amounts of data because of the limit on the URL length.
Another technique uses cross-domain scripting citation. A web page in a domain uses the <script> label to reference Javascript (JS) file contents of another domain and transfers the data in the form of URL parameters. The JS file of the other domain can compile script freely to send the data directly to the current web page. This technique tends to be complex since new script needs to be generated in each communication. Further, the data of one domain would be completely exposed to the script of another and can be easily misappropriated.
BRIEF DESCRIPTION OF THE DRAWINGS
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
FIG. 1 is a block diagram illustrating an embodiment of a system that supports cross-domain communication.
FIG. 2A is a flowchart illustrating an embodiment of a process for cross-domain communication.
FIG. 2B is a flowchart illustrating an embodiment of a process for cross-domain communication.
FIG. 3 is a flowchart illustrating another embodiment of a process for cross-domain communication.
FIG. 4 is a system diagram illustrating an embodiment of a cross-domain communication system.
FIG. 5 is a block diagram illustrating an embodiment of a sender device.
FIG. 6 is a block diagram illustrating an embodiment of a receiver device.
DETAILED DESCRIPTION
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
Cross-domain communication is disclosed. As used herein, a domain refers to a collection of network devices organized under a common network name, such as www.example.com. The techniques can be used for implementing safe communication among different domains while guaranteeing security isolation of domains with respect to browser software.
FIG. 1 is a block diagram illustrating an embodiment of a system that supports cross-domain communication. In this example, system 100 includes a first domain 104 and a second domain 106, which in this example are shown to be isv.com and alisoft.com, respectively. For purposes of example, in the following discussion domain 104 is presumed to be the domain from which a data request is sent and is referred to as the first domain or the sender domain and domain 106 is presumed to be the domain to which a data request is received and is referred to as the second domain or the receiver domain. Communication in the reverse direction where domain 106 is the sender domain and domain 104 is the receiver domain is possible. One or more servers are included in the domains to provide web services such as displaying web pages and responding to client requests. In some embodiments, different physical servers are included in different domains. In some embodiments, a physical server device is virtualized to operate as multiple virtual servers that separately service different domains.
Within domain 104, there are one or more web pages that can be accessed by client devices such as 102 via client software such as a web browser. A designated response processing page (also referred to as the ACK page), in this case with the Universal Resource Locator (URL) of isv.com/ack.htm, is also included in the sender domain. Within domain 106, a designated request processing page (also referred to as the ASK page), in this case with the URL of alisoft.com/ask.htm, is configured to handle cross-domain transfer requests from outside domains such as domain 104. Details of the page configurations and operations are described below.
FIG. 2A is a flowchart illustrating an embodiment of a process for cross-domain communication. Process 200 may be implemented on a device such as a server implementing services for domain 104.
At 202, a data request is sent from the sender domain to the receiver domain. The request may be evoked in response to a client action that is made on a webpage that is not specifically designated for cross-domain communication. Such a webpage is referred to as an originating page. As will be described more fully below, the data request is sent to a designated request processing page in the receiver domain. The designated request processing page is specifically configured to respond to cross-domain data request requests.
At 204, a response is received from the receiver domain. If the communication session is successful, the response would include requested data. The response is directed to a designated response processing page in the sender domain. The response is processed by the response processing page and information is passed to the originating page as appropriate.
At 206, the response is processed and can be passed on to the originating page as appropriate.
FIG. 2B is a flowchart illustrating an embodiment of a process for cross-domain communication. Process 250 may be implemented on a device such as a server implementing services for domain 106.
At 252, a data request from the sender domain is received in the receiver domain. The data request is directed to a designated request processing page in the receiver domain.
At 254, the data request is processed. Information relating to the response is gathered and a response is generated.
At 256, the response is sent to a designated response processing page in the sender domain to be processed and passed on to the originating page as appropriate.
The above cross-domain communication technique observes the security isolation mechanisms of browser domains, without requiring decreased browser security standards, URL page jumping, or substantially increased server load. It guarantees fair and symmetrical security protection for both sides for communication.
Referring back to FIG. 1, before any cross-domain communication takes place, the server of the sender domain deploys a designated response processing page and the server of the receiver domain deploys a designated request processing page. During the course of cross-domain communication that is initiated by a client browser, the browser opens the designated pages to transfer data for cross-domain communication. As used herein, “deploy” refers to placing these page files on the appropriate server and “open” refers to sending a request to a page file by a client browser.
Initially, the client browser loads the originating page, which is a page that initiates cross domain communication. For example, the originating page may be a login page for the sender domain that requires certain information from the receiver domain (e.g., user account in the receiver domain) to complete the login process in the sender domain. The originating page locates the name of the sender domain, such as isv.com.
During the course of cross-domain data transfer, when an originating page in the sender domain sends a cross-domain transferring request and parameters to the receiver domain, the browser that loaded the originating page will open a hidden page on the server in the sender domain, use the hidden page to open a an ASK page deployed on the server of the receiver domain and transfer the command and the data associated with the communication request using an a URL fragment identifier of the request and the name property of a window object of the page.
The receiver domain receives the request command and data at the designated request processing page, also referred to as the ASK page. Data pertaining to the response of the request is extracted. Since the ASK page is located in the receiver domain, such as alisoft.com, it can acquire related data in the domain according to the request that is received.
Once the result data is obtained, the ASK page opens the designated response processing page (i.e., the ACK page) on the sender domain or opens another hidden page and uses the hidden page to open the ACK page and sends the returning position and the response data using an a URL fragment identifier and the name property of a window object of the page. Since the ACK page is located in the sender domain, such as isv.com, it can return the response data to the originating page in the same domain.
The ASK page is used for receiving request command commands for cross-domain transfer and extracting response data according to the command commands. The ACK page is used for receiving the response data sent by the ASK page and returning the response data to the originating page in the sender domain. The sender and receiver domains only need to exchange data via their respective servers the first time a specific cross-domain communication is made. In subsequent cross-domain transfers, the browser will use its cache function to cache the parameters sent the first time and the receiver of communication extracts the resulting data from the browser directly when receiving a cross-domain transfer request.
FIG. 3 is a flowchart illustrating another embodiment of a process for cross-domain communication.
At 302, the servers on the sender and receiver domains deploy the designated response processing ACK page and the designated request processing ASK page, respectively. Bi-direction communications can be achieved by each domain deploying both an ACK page and an ASK page.
The designated request processing ASK page is a static page in some embodiments and a dynamic page in some embodiments where additional Hypertext Transfer Protocol (HTTP) header information is added. The response processing ACK page is a static page in some embodiments. ASK pages and ACK pages are basic pages for communication between two domains. They are collectively referred to as communication pages.
The communication pages agree on the same request format and follow the same communication protocol. In some embodiments, the HTTP GET request can be used for a requesting page and command, and communication commands and data are not transferred as URL parameters.
At 304, when an originating page in a website sends a communication request to another website in a different domain, the browser of the originating page is directed to open a hidden page. In some embodiments, opening the hidden page includes opening an invisible new window or an invisible iframe.
At 306, the hidden page opens the ASK page deployed on the server of the receiver domain and a request command and parameters are transferred.
In some embodiments, the request command is transferred in the form of a fragment identifier attached to the URL and the data can be transferred in the form of the name property of a window object. Specifically, the fragment identifier is attached to the URL by appending a “#” identifier to the URL and appending a string to “#.”. A fragment identifier can be used for locating a designated anchor node (reading position) in a page and is processed by the client rather than the server. URLs with or without a fragment identifier or with different fragment identifiers are considered to be the same URL for the server and are cached the same way by the browser. Therefore, data is exchanged the first time the URL is requested and is cached in the browser and available for subsequent requests without requiring further data exchange between the servers and the browser.
At 308, after receiving the request, the ASK page in the receiver domain implements corresponding service and
At 310, the ASK page in the receiver domain opens a hidden new page or uses the ASK page itself to open the ACK page in the sender domain and transfers the response data to the ACK page in the sender domain.
The security isolation mechanism built into the browser forbids a program of a page in one domain to operate the content and data of another page directly. But when a page in one domain can open a page in another domain, transferring data to a page in the other domain is permitted in the form of a URL or the name property of a window object.
At 312, the ACK page in the original domain website returns the response data received to the originating page.
The steps above can be described by an example. For example, a typical request from a sender domain www.isv.com to a ASK page in a receiver domain www.alisoft.com is as follows:
http://www.alisoft.com/ASK.HTM#GetUserName/envoy123@www.isv.com
The page http://www.alisoft.com/ASK.HTM is requested for the user name of an email address envoy123@www.isv.com (GetUserName).
A typical response to the ASK page is as follows:
http://www.isv.com/ACK.HTM#bob321.
Strings bob321 to the page http://www.isv.com/ACK.HTM as the response to the request above.
Note that since the ACK page and the originating page are located in the same domain, the ACK page can visit the originating page and thus transfer the resulting data to the originating page.
In the example above, request and response data are transferred in the form of strings in JSON format. JSON format is native data expression form for JavaScript language and has the advantages of simple form, compact format and convenient conversion. Data can be transferred by the name property of window object, by which large amount data amounts of data can be transferred. Data also can be transferred all by fragment identifiers.
In some embodiments, in order to facilitate the use for developers, the data above can be packaged into a series of JavaScript functions to developers. For example: function envoy (domainName, serviceName, on Success, on Error), in which domainName is the domain name for communication, serviceName is the service name being requested, on Success indicates the return function upon success and on Error indicates the return function upon failure.
Safe communications among different domains are implemented with obeying the security isolation mechanism of browser domains completely, without requiring visitors to decrease security standards, URL page jumping nor requesting to servers frequently. It guarantees fair and symmetrical security protection for both sides for communication.
FIG. 4 is a system diagram illustrating an embodiment of a cross-domain communication system. In this example, the system includes a sender device 100 410 and a receiver device 200 420 that belong to different domains.
The sender 100 410 is implemented in some embodiments as a server configured to send a request to the designated request processing page on the receiver 200 420 and to receive a response sent by the designated request processing page on the receiver, at a designated local response processing page on the sender.
The receiver 200 420 is implemented in some embodiments as a server configured to receive the request sent by the sender 100 410 via the designated request processing page, processing the request sent by the sender 100 410 and acquiring response data and sending the response to the response processing page on receiver 100 sender 410.
FIG. 5 is a block diagram illustrating an embodiment of a sender device. In this example, the device includes a request sending module 10, a response receiving module 20 and a data acquiring module 30.
The request sending module 10 is configured to a request to the designated request processing page in the receiver. It further includes an originating page configured to send data such as the request command and associated data. The response receiving module 20 is configured to process a response sent by the receiver. It further includes a designated response processing page configured to receive the response. The data acquiring module 30 is configured to acquire the response from the page for receiving data in the sender.
FIG. 6 is a block diagram illustrating an embodiment of a receiver device for cross-domain communication. The device in this example includes a request receiving module 40, a processing module 50 and a response sending module 60.
The request receiving module 40 is configured to receive a request from a sender. It further includes a designated request processing page configured to receive the request command and associated data. The processing module 50 is configured to process the request sent by the sender and to acquire response data. The response sending module 60 is used for sending the response to a designated response processing page on the sender.
In some embodiments, a device may be configured both as a sender and a receiver and includes all the modules shown in FIGS. 5 and 6. In such embodiments, the designated request processing page and the designated response processing page can be different pages or the same page. The page(s) can be configured as dynamic pages or static pages.
Safe communications among different domains are implemented with obeying the security isolation mechanism of browser domains completely, without needing visitors to decrease security standards, URL page jumping nor requesting to servers frequently. It guarantees fair and symmetrical security protection for both sides for communication.
The modules described above can be implemented as software components executing on one or more general purpose processors, as hardware such as programmable logic devices and/or Application Specific Integrated Circuits designed to perform certain functions or a combination thereof. In some embodiments, the modules can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as CD-ROM, U disk, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, network equipments, etc.) implement the methods described in the embodiments of the present invention. The modules may be implemented on a single device or distributed across multiple devices. The functions of the modules may be merged into one another or further split into multiple sub-modules.
Through the description of the embodiments above, the technical personnel in this field can understand clearly that the present invention can be implemented by hardware or software and a necessary current hardware platform. Based on this understanding, the technical program of the present invention can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as CD-ROM, U disk, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, or network equipments equipment, etc.) implement the methods described in the embodiments of the present invention.
The descriptions above are just preferred implementation ways of the present invention. It should be pointed that, for general technical personnel in this field, some improvement and decorating can be done, which should be under the protection scope of the present invention.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims (17)

What is claimed is:
1. A sender system for cross-domain communication between a sender domain and a receiver domain that is different from the sender domain, comprising:
a hardware processor configured to:
send a data request from an originating webpage deployed in the sender domain to the receiver domain, the data request being directed to a designated request processing page in the receiver domain, wherein sending the data request from the sender domain to the receiver domain includes opening a hidden page and using the hidden page to open the designated response request processing page and to send a request command and associated request data via the hidden page, wherein opening the hidden page includes opening an invisible new window or an invisible iframe;
receive a response from the receiver domain, the response including requested data and being directed to a designated response processing page in the sender domain, wherein the designated response processing page deployed in the sender domain is a different webpage from the originating webpage deployed in the sender domain; and
process the response; and
a memory coupled to the hardware processor, configured to provide the hardware processor with instructions.
2. The system of claim 1, wherein the data request is sent in response to a client action from a browser to an the originating webpage in the sender domain.
3. The system of claim 1, wherein the designated request processing page is deployed in the receiver domain and the designated response processing page is deployed in the sender domain prior to the cross-domain communication.
4. The system of claim 1, wherein the data request includes a request command and associated request data that are sent via a Hypertext Transfer Protocol (HTTP) GET command.
5. The system of claim 1, wherein:
the data request includes a request command and associated request data;
the request command is sent as a fragment identifier attached to a uniform resource locator (URL); and
the associated data are is transferred as a name property of a window object.
6. The system of claim 1, wherein:
the data request includes a request command and associated request data; and
the request command and the associated request data are sent as a fragment identifier attached to a URL.
7. The system of claim 1, wherein request data is transferred as a string in JSON format.
8. The system of claim 1, wherein processing the response includes transferring response data from the designated response processing page to the originating webpage.
9. A method for cross-domain communication between a sender domain and a receiver domain that is different from the sender domain, comprising:
sending a data request from an originating webpage deployed in the sender domain to the receiver domain, the data request being directed to a designated request processing page in the receiver domain, wherein sending the data request from the sender domain to the receiver domain includes opening a hidden page and using the hidden page to open the designated response request processing page and to send a request command and associated request data via the hidden page, wherein opening the hidden page includes opening an invisible new window or an invisible iframe;
receiving a response from the receiver domain, the response including requested data and being directed to a designated response processing page in the sender domain, wherein the designated response processing page deployed in the sender domain is a different webpage from the originating webpage deployed in the sender domain; and
processing, by one or more hardware processors, the response.
10. The method of claim 9, wherein the data request is sent in response to a client action from a browser to an the originating webpage in the sender domain.
11. The method of claim 9, wherein the designated request processing page is deployed in the receiver domain and the designated response processing page is deployed in the sender domain prior to the cross-domain communication.
12. The method of claim 9, wherein the data request includes a request command and associated request data that are sent via a Hypertext Transfer Protocol (HTTP) GET command.
13. The method of claim 9, wherein:
the data request includes a request command and associated request data;
the request command is sent as a fragment identifier attached to a uniform resource locator (URL); and
the associated data are is transferred as a name property of a window object.
14. The method of claim 9, wherein:
the data request includes a request command and associated request data; and
the request command and the associated request data are sent as a fragment identifier attached to a URL.
15. The method of claim 9, wherein request data is transferred as a string in JSON format.
16. A receiver system for cross-domain communication between a sender domain and a receiver domain that is different from the sender domain, comprising:
a processor configured to:
receive, in the receiver domain, a data request from an originating webpage deployed in the sender domain, the data request being directed to a designated request processing page in the receiver domain, wherein sending the data request from the sender domain to the receiver domain includes opening a hidden page and using the hidden page to open the designated response request processing page and to send a request command and associated request data via the hidden page, wherein opening the hidden page includes opening an invisible new window or an invisible iframe;
process the data request to generate a response; and
send the response to the sender domain, the response being directed to a designated response processing page in the sender domain, wherein the designated response processing page deployed in the sender domain is a different webpage from the originating webpage deployed in the sender domain; and
a memory coupled to the processor, configured to provide the processor with instructions.
17. A method for cross-domain communication between a sender domain and a receiver domain that is different from the sender domain, comprising:
receiving, in the receiver domain, a data request from an originating webpage deployed in the sender domain, the data request being directed to a designated request processing page in the receiver domain, wherein sending the data request from the sender domain to the receiver domain includes opening a hidden page and using the hidden page to open the designated response request processing page and to send a request command and associated request data via the hidden page, wherein opening the hidden page includes opening an invisible new window or an invisible iframe;
processing, by one or more hardware processors, the data request to generate a response; and
sending the response to the sender domain, the response being directed to a designated response processing page in the sender domain, wherein the designated response processing page deployed in the sender domain is a different webpage from the originating webpage deployed in the sender domain.
US14/139,426 2008-08-25 2013-12-23 Method and apparatus for cross-domain communication using designated response processing page Active 2029-11-28 USRE45139E1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/139,426 USRE45139E1 (en) 2008-08-25 2013-12-23 Method and apparatus for cross-domain communication using designated response processing page

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200810147259.3A CN101662460B (en) 2008-08-25 2008-08-25 Method, system and device for cross-domain communication
CN200810147259 2008-08-25
US12/583,362 US8090763B2 (en) 2008-08-25 2009-08-18 Method and apparatus for cross-domain communication using designated response processing page
US14/139,426 USRE45139E1 (en) 2008-08-25 2013-12-23 Method and apparatus for cross-domain communication using designated response processing page

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/583,362 Reissue US8090763B2 (en) 2008-08-25 2009-08-18 Method and apparatus for cross-domain communication using designated response processing page

Publications (1)

Publication Number Publication Date
USRE45139E1 true USRE45139E1 (en) 2014-09-16

Family

ID=41697321

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/583,362 Ceased US8090763B2 (en) 2008-08-25 2009-08-18 Method and apparatus for cross-domain communication using designated response processing page
US14/139,426 Active 2029-11-28 USRE45139E1 (en) 2008-08-25 2013-12-23 Method and apparatus for cross-domain communication using designated response processing page

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/583,362 Ceased US8090763B2 (en) 2008-08-25 2009-08-18 Method and apparatus for cross-domain communication using designated response processing page

Country Status (6)

Country Link
US (2) US8090763B2 (en)
EP (1) EP2318941A4 (en)
JP (1) JP5689799B2 (en)
CN (1) CN101662460B (en)
HK (1) HK1141170A1 (en)
WO (1) WO2010024863A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120303453A1 (en) * 2011-05-26 2012-11-29 Yahoo! Inc. Methods and systems for securely targeting advertisements on login pages

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8914539B2 (en) * 2010-03-12 2014-12-16 Salesforce.Com, Inc. Service cloud console
US8539234B2 (en) * 2010-03-30 2013-09-17 Salesforce.Com, Inc. Secure client-side communication between multiple domains
CN102486780A (en) * 2010-12-01 2012-06-06 腾讯科技(深圳)有限公司 Method, client and server for asynchronous cross-domain transmission on extensible markup language (XML) data
CN102571851B (en) * 2010-12-27 2015-03-25 阿里巴巴集团控股有限公司 Data communication method and system
CN102307220B (en) * 2011-03-18 2014-04-02 北京思特奇信息技术股份有限公司 Cross-domain webpage information interaction method
CN102184220A (en) * 2011-05-06 2011-09-14 中兴通讯股份有限公司 Cross-domain page display control method and device
US9215096B2 (en) 2011-08-26 2015-12-15 Salesforce.Com, Inc. Computer implemented methods and apparatus for providing communication between network domains in a service cloud
CN102984179A (en) * 2011-09-02 2013-03-20 广东电子工业研究院有限公司 Cloud-computing operating system oriented method for cross-domain access to Web services
US8898780B2 (en) * 2011-11-07 2014-11-25 Qualcomm Incorporated Encoding labels in values to capture information flows
US20140376371A1 (en) * 2012-01-02 2014-12-25 Nokia Solutions And Networks Oy Method and Device for Conveying Data Across at Least Two Domains
CN103246667A (en) * 2012-02-08 2013-08-14 腾讯科技(深圳)有限公司 Method and device for cross-domain transfer of data
CN103294672B (en) * 2012-02-23 2017-05-10 腾讯科技(深圳)有限公司 Method, system and device for realizing cross-domain drag
CN103309861B (en) * 2012-03-07 2018-04-10 阿里巴巴集团控股有限公司 The method and apparatus that cross-domain data obtains
CN103309877B (en) * 2012-03-12 2017-04-05 腾讯科技(深圳)有限公司 The method of cross-domain communication and full duplex communication, device
US20130262977A1 (en) * 2012-03-30 2013-10-03 International Business Machines Corporation Controlling Browser Preferences with a Rich Internet Application
CN102662600B (en) * 2012-04-28 2013-11-27 北京亿中邮信息技术有限公司 Method for mutually dragging files at different domain names
US9154470B2 (en) 2012-05-25 2015-10-06 Canon U.S.A., Inc. System and method for processing transactions
CN103634338B (en) * 2012-08-21 2017-04-12 北京亿赞普网络技术有限公司 Method for modifying primary domain name of webpage online, data processing device and system
CN103152445B (en) * 2013-04-03 2016-02-03 晶赞广告(上海)有限公司 A kind of asynchronous cross-domain identify label mapping method of internet security
CN104426864B (en) * 2013-08-28 2019-01-08 腾讯科技(深圳)有限公司 The realization method and system of cross-region remote order
CN103546570A (en) * 2013-10-29 2014-01-29 小米科技有限责任公司 Method, device and terminal for achieving network client-side cross-domain data request
CN103870551B (en) * 2014-02-28 2018-02-23 小米科技有限责任公司 The method and apparatus that a kind of cross-domain data obtains
CN104301379A (en) * 2014-08-28 2015-01-21 北京奇虎科技有限公司 Web page cross-domain communication method and device
CN105471824A (en) * 2014-09-03 2016-04-06 阿里巴巴集团控股有限公司 Method, device and system for invoking local service assembly by means of browser
CN104572263B (en) * 2014-12-30 2017-11-07 腾讯科技(深圳)有限公司 A kind of page data exchange method, relevant apparatus and system
CN105491116B (en) * 2015-11-26 2019-04-26 广州华多网络科技有限公司 A kind of cross-window submits the method and system of data
GB2548405B (en) * 2016-03-18 2019-08-14 Advanced Risc Mach Ltd Combination of control interfaces for multiple communicating domains
CN107220260B (en) 2016-03-22 2020-07-24 阿里巴巴集团控股有限公司 Page display method and device
CN107070870B (en) * 2017-01-09 2020-04-14 阿里巴巴集团控股有限公司 Data acquisition method and device
US11165751B2 (en) 2017-02-16 2021-11-02 Emerald Cactus Ventures, Inc. System and method for establishing simultaneous encrypted virtual private networks from a single computing device
US11122013B2 (en) * 2017-02-16 2021-09-14 Emerald Cactus Ventures, Inc. System and method for encrypting data interactions delineated by zones
WO2018151847A1 (en) 2017-02-16 2018-08-23 Tenta, Llc System and method for creating encrypted virtual private network hotspot
US10733376B2 (en) * 2017-03-01 2020-08-04 Google Llc Delivering auto-play media content element from cross origin resources
CN107749858A (en) * 2017-11-06 2018-03-02 郑州云海信息技术有限公司 The method for switching between and device of a kind of end points
CN110209959B (en) * 2018-02-11 2024-01-12 北京京东尚科信息技术有限公司 Information processing method and device
CN110928699A (en) * 2018-09-20 2020-03-27 北京京东尚科信息技术有限公司 Front-end cross-domain event processing method and device
CN109450973A (en) * 2018-09-29 2019-03-08 福建威盾科技有限公司 A kind of method that cross-domain browser data is shared
CN111049851B (en) * 2019-12-24 2021-10-01 中国电子科技集团公司第五十四研究所 Multi-level and multi-dimensional linkage management and control system for cross-domain transmission service
CN112905940A (en) * 2021-02-25 2021-06-04 平安普惠企业管理有限公司 Page communication method and device, computer equipment and storage medium

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5142622A (en) 1989-01-31 1992-08-25 International Business Machines Corporation System for interconnecting applications across different networks of data processing systems by mapping protocols across different network domains
US5802590A (en) 1994-12-13 1998-09-01 Microsoft Corporation Method and system for providing secure access to computer resources
US5895499A (en) 1995-07-03 1999-04-20 Sun Microsystems, Inc. Cross-domain data transfer using deferred page remapping
US5961593A (en) 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6125384A (en) 1996-12-23 2000-09-26 International Business Machines Corporation Computer apparatus and method for communicating between software applications and computers on the world-wide web
US20030023445A1 (en) 2001-04-25 2003-01-30 Gal Trifon Method for dynamically changing one Web page by another web page
US6934757B1 (en) 2000-01-06 2005-08-23 International Business Machines Corporation Method and system for cross-domain service invocation using a single data handle associated with the stored common data and invocation-specific data
US20060010134A1 (en) 2004-07-09 2006-01-12 Ebay Inc. Method and apparatus for securely displaying and communicating trusted and untrusted internet content
WO2007047765A2 (en) 2005-10-14 2007-04-26 Ebay Inc. Asynchronously loading dynamically generated content across multiple internet domains
US20070113237A1 (en) 2005-11-17 2007-05-17 Ian Hickson Method and device for event communication between documents
US20070256003A1 (en) 2006-04-24 2007-11-01 Seth Wagoner Platform for the interactive contextual augmentation of the web
US20070299735A1 (en) 2006-06-27 2007-12-27 Piyush Mangalick Cross domain customer interface updates
US20070300064A1 (en) 2006-06-23 2007-12-27 Microsoft Corporation Communication across domains
US20070299857A1 (en) 2006-06-23 2007-12-27 Microsoft Corporation Cross Domain Communication
US20080010359A1 (en) 2006-07-10 2008-01-10 Jeffrey Mark Achtermann Computer implemented method and system for managing server-based rendering of messages in a heterogeneous environment
US20080034441A1 (en) 2006-08-07 2008-02-07 Shoumen Saha Updating content within a container document for user groups
US20080033956A1 (en) 2006-08-07 2008-02-07 Shoumen Saha Distribution of Content Document to Varying Users With Security Customization and Scalability
US20080046562A1 (en) 2006-08-21 2008-02-21 Crazy Egg, Inc. Visual web page analytics
US20080281944A1 (en) 2007-05-07 2008-11-13 Vorne Industries, Inc. Method and system for extending the capabilities of embedded devices through network clients
US20080298342A1 (en) 2007-05-28 2008-12-04 Benjamin Charles Appleton Inter-Domain Communication
US20090006996A1 (en) 2006-08-07 2009-01-01 Shoumen Saha Updating Content Within A Container Document For User Groups
US20090037806A1 (en) 2007-07-30 2009-02-05 Jun Yang Cross-Domain Communication
US20090199083A1 (en) 2008-01-17 2009-08-06 Can Sar Method of enabling the modification and annotation of a webpage from a web browser
US20090248494A1 (en) 2008-04-01 2009-10-01 Certona Corporation System and method for collecting and targeting visitor behavior
US20090293018A1 (en) 2008-05-23 2009-11-26 Jeffrey Wilson History-based tracking of user preference settings
US7640512B1 (en) 2000-12-22 2009-12-29 Automated Logic Corporation Updating objects contained within a webpage
US20090328063A1 (en) 2008-06-27 2009-12-31 Microsoft Corporation Inter-frame messaging between different domains
US20100088354A1 (en) 2006-11-30 2010-04-08 Alibaba Group Holding Limited Method and System for Log File Analysis Based on Distributed Computing Network

Patent Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5142622A (en) 1989-01-31 1992-08-25 International Business Machines Corporation System for interconnecting applications across different networks of data processing systems by mapping protocols across different network domains
US5802590A (en) 1994-12-13 1998-09-01 Microsoft Corporation Method and system for providing secure access to computer resources
US5895499A (en) 1995-07-03 1999-04-20 Sun Microsystems, Inc. Cross-domain data transfer using deferred page remapping
US6125384A (en) 1996-12-23 2000-09-26 International Business Machines Corporation Computer apparatus and method for communicating between software applications and computers on the world-wide web
US5961593A (en) 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6934757B1 (en) 2000-01-06 2005-08-23 International Business Machines Corporation Method and system for cross-domain service invocation using a single data handle associated with the stored common data and invocation-specific data
US7640512B1 (en) 2000-12-22 2009-12-29 Automated Logic Corporation Updating objects contained within a webpage
US20030023445A1 (en) 2001-04-25 2003-01-30 Gal Trifon Method for dynamically changing one Web page by another web page
US8280819B2 (en) 2004-07-09 2012-10-02 Ebay Inc. Method and apparatus for securely displaying and communicating trusted and untrusted internet content
US20060010134A1 (en) 2004-07-09 2006-01-12 Ebay Inc. Method and apparatus for securely displaying and communicating trusted and untrusted internet content
WO2007047765A2 (en) 2005-10-14 2007-04-26 Ebay Inc. Asynchronously loading dynamically generated content across multiple internet domains
US7506248B2 (en) 2005-10-14 2009-03-17 Ebay Inc. Asynchronously loading dynamically generated content across multiple internet domains
US20070113237A1 (en) 2005-11-17 2007-05-17 Ian Hickson Method and device for event communication between documents
US20070256003A1 (en) 2006-04-24 2007-11-01 Seth Wagoner Platform for the interactive contextual augmentation of the web
US20070300064A1 (en) 2006-06-23 2007-12-27 Microsoft Corporation Communication across domains
US20070299857A1 (en) 2006-06-23 2007-12-27 Microsoft Corporation Cross Domain Communication
US8250082B2 (en) 2006-06-23 2012-08-21 Microsoft Corporation Cross domain communication
US20070299735A1 (en) 2006-06-27 2007-12-27 Piyush Mangalick Cross domain customer interface updates
US20080010359A1 (en) 2006-07-10 2008-01-10 Jeffrey Mark Achtermann Computer implemented method and system for managing server-based rendering of messages in a heterogeneous environment
US20080033956A1 (en) 2006-08-07 2008-02-07 Shoumen Saha Distribution of Content Document to Varying Users With Security Customization and Scalability
US20090006996A1 (en) 2006-08-07 2009-01-01 Shoumen Saha Updating Content Within A Container Document For User Groups
US20090037935A1 (en) 2006-08-07 2009-02-05 Shoumen Saha Updating The Configuration of Container Documents
US20080034441A1 (en) 2006-08-07 2008-02-07 Shoumen Saha Updating content within a container document for user groups
US20080046562A1 (en) 2006-08-21 2008-02-21 Crazy Egg, Inc. Visual web page analytics
US20100088354A1 (en) 2006-11-30 2010-04-08 Alibaba Group Holding Limited Method and System for Log File Analysis Based on Distributed Computing Network
US20080281944A1 (en) 2007-05-07 2008-11-13 Vorne Industries, Inc. Method and system for extending the capabilities of embedded devices through network clients
US20080298342A1 (en) 2007-05-28 2008-12-04 Benjamin Charles Appleton Inter-Domain Communication
US20090037806A1 (en) 2007-07-30 2009-02-05 Jun Yang Cross-Domain Communication
US20090199083A1 (en) 2008-01-17 2009-08-06 Can Sar Method of enabling the modification and annotation of a webpage from a web browser
US20090248494A1 (en) 2008-04-01 2009-10-01 Certona Corporation System and method for collecting and targeting visitor behavior
US20090293018A1 (en) 2008-05-23 2009-11-26 Jeffrey Wilson History-based tracking of user preference settings
US20090328063A1 (en) 2008-06-27 2009-12-31 Microsoft Corporation Inter-frame messaging between different domains

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
U.S. Appl. No. 11/426,174, Gwozdz et al.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120303453A1 (en) * 2011-05-26 2012-11-29 Yahoo! Inc. Methods and systems for securely targeting advertisements on login pages

Also Published As

Publication number Publication date
WO2010024863A1 (en) 2010-03-04
EP2318941A4 (en) 2013-05-08
HK1141170A1 (en) 2010-10-29
EP2318941A1 (en) 2011-05-11
CN101662460B (en) 2015-07-15
CN101662460A (en) 2010-03-03
JP2012501034A (en) 2012-01-12
US8090763B2 (en) 2012-01-03
US20100049782A1 (en) 2010-02-25
JP5689799B2 (en) 2015-03-25

Similar Documents

Publication Publication Date Title
USRE45139E1 (en) Method and apparatus for cross-domain communication using designated response processing page
US8819819B1 (en) Method and system for automatically obtaining webpage content in the presence of javascript
US9697188B2 (en) Method to enable cross-origin resource sharing from a webpage inside a private network
US8448241B1 (en) Browser extension for checking website susceptibility to cross site scripting
US11736446B2 (en) Object property getter and setter for clientless VPN
Putthacharoen et al. Protecting cookies from cross site script attacks using dynamic cookies rewriting technique
US10783019B1 (en) Single page application content injection
US9509691B2 (en) Secure transfer of web application client persistent state information into a new domain
US11836213B2 (en) Encoding-free JavaScript stringify for clientless VPN
CN105959278A (en) Method, device and system for calling VPN
CN108282537A (en) A kind of method that Portal User is offline and access device
CN105205078A (en) Webpage access method and device
GB2545895A (en) A method and apparatus for detecting exploits
Lekies et al. Towards stateless, client-side driven Cross-Site Request Forgery protection for Web applications
CN113992446A (en) Cross-domain browser user authentication method, system and computer storage medium
US10831836B2 (en) Browser storage for clientless VPN
JP2010079431A (en) Information leakage prevention program
TWI486039B (en) Inter-domain communication methods, systems and devices
CN116436705B (en) Network security detection method and device, electronic equipment and storage medium
Petty The Not-So-Same-Origin Policy
TWI234377B (en) Network security protection system
Afek et al. Localhost Detour from Public to Private Networks
Nu1L Team Advanced Web
US20100083231A1 (en) System And Method For Safe Code Loading
JP5893787B2 (en) Information processing apparatus, processing method, and program

Legal Events

Date Code Title Description
AS Assignment

Owner name: ALIBABA GROUP HOLDING LIMITED, CAYMAN ISLANDS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LI, ZHANYUAN;REEL/FRAME:032187/0399

Effective date: 20090806

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12