JP2016091449A - Local storage synchronization method, local storage synchronizer and local storage synchronization program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To synchronize local storage between a plurality of browsers.SOLUTION: A local storage synchronizer 10 receives a request 15 to a server 2 from a browser 13, and inserts script 16a showing processing for transmitting a request 17 into data 16 to transmit the data to the browser 13. The local storage synchronizer 10 receives the request 17 from the browser 13, and transmits data 18 including script 18a showing processing for detecting update of local storage 13a and transmitting update information 19 to the browser 13. The local storage synchronizer 10 receives the update information 19 from the browser 13, and transmits the update information 19 to a browser 14 in the case that the browser 14 currently performs execution.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a local storage synchronization method, a local storage synchronization apparatus, and a local storage synchronization program.

  When a user uses WWW (World Wide Web), application software called a browser is executed on a client device used by the user. The browser communicates with a server device on which server software called a Web server operates, and mainly provides a visual user interface based on the communication result.

  The browser transmits an HTTP (Hypertext Transfer Protocol) request to the Web server, and receives an HTTP response including a file requested by the HTTP request. The received file indicates the content of the Web page to be displayed, and is described using a markup language such as HTML (HyperText Markup Language). A script, which is a program executed on the browser, may be added to the received file. The browser draws (renders) a Web page in the display area based on the received file. When a script is added to the file, the browser executes the script and controls the display of the Web page according to the execution result.

  By utilizing the script, it becomes possible to provide a user with a Web page with high operability. On the other hand, a script is a program created by a third party and may pose a threat to security. Therefore, it is not preferable to execute the received script on the browser without limit. Therefore, browsers limit the processes that can be executed by scripts. For example, with respect to network access, the browser limits the access destination that can be specified from a script to the same Web site as the script. In addition, regarding the local storage area on the client device, the browser limits the storage area that can be used from the script to the limited storage area managed by the browser.

  Conventionally, regarding a local storage area that can be used from a script, a small-capacity data storage destination called “cookie” has been used. On the other hand, in recent years, there is a need to handle large-size data on a browser in order to realize a Web page with higher operability. Accordingly, HTML5, which is a markup language standard, defines a large-capacity (for example, 10 MB or more) storage area called “local storage”. Data stored in the local storage is retained even after the browser is closed.

  The script can store various data in the local storage. For example, consider a web page that stores data entered by the user in the local storage while the browser is offline, and then sends the local storage data to the web server when the browser is next online. It is done. Thus, by utilizing the local storage, the user can perform various operations intermittently on the browser without continuously connecting the client device to the network.

  A system for synchronizing data among a plurality of client devices such as a PC (Personal Computer) and a mobile phone has been proposed. A client device included in this system uploads a change log of data such as address information, schedule information, Web site link information, and a document file to a server device on the network. Other client devices download the change log from the server device and synchronize the data.

  In addition, a Web data platform that is executed on a client device that receives Web data from a server device has been proposed. The Web data platform stores received Web data in a client device, and makes it possible to access the stored Web data from application software executed on the client device.

  In addition, a system capable of executing processing on a browser in an offline state not connected to a network has been proposed. A client device included in this system receives Web content including HTML data and a script from the server device, and stores the received Web content in the client device. When the client device is in an offline state, the client device displays a Web page using the stored Web content.

JP 2002-163137 A International Publication No. 2008/054951 International Publication No. 2008/100881

  The user can use a plurality of browsers. For example, a plurality of browsers can be installed on one client device. Thus, accessing the same Web site from different browsers can occur. For example, a user may browse a website on which browser A is activated on a certain day, and activate browser B on the next day to browse the same website. However, the local storage is a storage area closed for each browser. For this reason, different data may be stored in the local storage among a plurality of browsers. This can cause various problems with data consistency.

  For example, it is assumed that the user activates browser A on one day and inputs data in an offline state, and activates browser B on the next day and inputs new data in an online state. Thereafter, when the browser A is activated in the online state and the Web site is accessed, the old data input before is uploaded from the local storage of the browser A to the Web server. As a result, the latest data input using the browser B may be lost. In addition, unintended old data may be disclosed.

  To solve this problem, it is conceivable to synchronize local storage among a plurality of browsers. However, from the viewpoint of security, access to the local storage of the browser is limited, and how to synchronize the local storage becomes a problem.

  In one aspect, an object of the present invention is to provide a local storage synchronization method, a local storage synchronization apparatus, and a local storage synchronization program for synchronizing local storage among a plurality of browsers.

  In one aspect, a computer-implemented local storage synchronization method is provided. A request addressed to the server is received from the first browser using the local storage. A script indicating a process for transmitting another request is inserted into the data corresponding to the request acquired from the server and transmitted to the first browser. Other requests are received from the first browser. In response to another request, other data including another script indicating processing for detecting update of the local storage and transmitting update information is transmitted to the first browser. Update information is received from the first browser. When the second browser using another local storage is running, the update information is transmitted to the second browser.

  In one aspect, a local storage synchronization apparatus having a communication unit and a control unit is provided. In one aspect, a local storage synchronization program to be executed by a computer is provided.

  In one aspect, local storage can be synchronized between multiple browsers.

It is a figure which shows the local storage synchronization apparatus of 1st Embodiment. It is a figure which shows the information processing system of 2nd Embodiment. It is a block diagram which shows the hardware example of a terminal device. It is a block diagram which shows the function example of a terminal device. It is a figure which shows the example of a synchronous data table. It is a figure which shows the example of an access information table. It is a sequence diagram which shows the example of Web access. It is a figure which shows the example of the script added to a web page. It is a figure which shows the example of the script contained in a control page. It is a flowchart which shows the example of a procedure of a proxy transfer process. It is a flowchart which shows the example of a procedure of a proxy synchronous process. It is a flowchart which shows the example of a procedure of a browser access process. It is a flowchart which shows the example of a procedure of a browser synchronous process.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
FIG. 1 is a diagram illustrating the local storage synchronization apparatus according to the first embodiment.

  The local storage synchronization apparatus 10 according to the first embodiment relays communication between the server 2 and the browsers 13 and 14. The server 2 is a server device that executes a Web server as a server application, for example. The browsers 13 and 14 are, for example, Web browsers as client applications that perform HTTP communication with the server 2 via the local storage synchronization apparatus 10. The browsers 13 and 14 may be executed on the local storage synchronization apparatus 10 or may be executed on another apparatus.

  The processing of the local storage synchronization apparatus 10 to be described later is implemented as a proxy server for the browsers 13 and 14, for example. In that case, the browsers 13 and 14 are set so that access to the server 2 passes through this proxy server.

  The browser 13 uses a local storage 13a that is a storage area provided in a device that executes the browser 13 (for example, the local storage synchronization device 10). Data can be stored in the local storage 13 a by a script executed on the browser 13. The data stored in the local storage 13a is retained even when the browser 13 is terminated. Further, the browser 14 uses a local storage 14a that is a storage area provided in a device (for example, the local storage synchronization device 10) that executes the browser 14. Data can be stored in the local storage 14 a by a script executed on the browser 14. The data stored in the local storage 14a is retained even when the browser 14 is terminated. The local storages 13a and 14a are formed on a nonvolatile storage device such as an HDD (Hard Disk Drive) or a flash memory, for example.

  The local storage synchronization apparatus 10 includes a communication unit 11 and a control unit 12. The communication unit 11 is a communication interface that communicates with the server 2. The communication unit 11 may be a wired interface or a wireless interface. The control unit 12 controls access from the browsers 13 and 14 to the server 2. The control unit 12 may be a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor). Further, the control unit 12 may include an electronic circuit for a specific application such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The processor executes a program stored in a memory such as a RAM (Random Access Memory). A set of multiple processors (multiprocessor) may be referred to as a “processor”.

  Here, when the browser 13 transmits the request 15 addressed to the server 2, the control unit 12 receives the request 15 from the browser 13. The request 15 is an HTTP request including an address such as a URL (Uniform Resource Locator). Upon receiving the request 15, the control unit 12 transfers the request 15 to the server 2 and receives data 16 (for example, data specified by a URL included in the request 15) corresponding to the request 15 from the server 2. The data 16 is, for example, an HTML file that describes the contents of a Web page using HTML. However, when the data 16 is cached in the local storage synchronization apparatus 10, the cached data 16 may be used.

  The control unit 12 inserts the script 16 a into the data 16 and transmits it to the browser 13. The script 16a indicates processing for transmitting the request 17. The request 17 is, for example, an HTTP request. If the request 17 includes a URL, the protocol scheme, host name, and port number of the URL are the same as those of the request 15. Thereby, data 18 and data 16 described later are recognized as data relating to the same Web site. Preferably, the request 17 includes a predetermined character string.

  The browser 13 that has received the data 16 displays a Web page in one window based on the data 16. Further, the browser 13 executes a script 16 a included in the data 16. Thereby, the browser 13 transmits a request 17.

  The control unit 12 receives the request 17 from the browser 13. Then, the control unit 12 transmits data 18 to the browser 13 as a response to the request 17. The data 18 is, for example, an HTML file indicating a Web page different from the data 16. Whether or not the data 18 is transmitted can be determined, for example, based on whether or not a predetermined character string is included in the received request. The data 18 includes a script 18a. The script 18a indicates a process of detecting an update of the local storage 13a and transmitting update information 19 including the content of the detected update. Data 16 and data 18 are recognized as data of the same Web site. Thereby, the script 18a can detect the update of the local storage 13a performed on the Web page displayed based on the data 16.

  The browser 13 that has received the data 18 displays a Web page based on the data 18. For example, the browser 13 displays the web page based on the data 18 in a window different from the web page based on the data 16. The “different windows” referred to here may include different tabs in the tab-type browser. When the local storage 13a is updated in the Web page based on the data 16 (for example, new data is stored), the browser 13 detects the update according to the script 18a and transmits update information 19.

  The control unit 12 receives the update information 19 from the browser 13. The control unit 12 transmits the update information 19 to the browser 14 when the browser 14 is being executed. When the browser 14 receives the update information 19, the browser 14 updates the local storage 14 a based on the update information 19. Thereby, the local storages 13a and 14a are synchronized. In order to realize this, the control unit 12 may transmit data including a script indicating a process of updating the local storage 14 a in response to reception of the update information 19 to the browser 14 in advance.

  When the browser 14 is not being executed when the update information 19 is received, the control unit 12 may store the update information 19 in a database using a storage area different from the local storages 13a and 14a. In this case, the control part 12 should just transmit the update information 19 stored in the database to the browser 14 after the browser 14 starts.

  According to the local storage synchronization apparatus 10 of the first embodiment, the script 16 a for transmitting the request 17 is inserted into the data 16 corresponding to the request 15 and transmitted to the browser 13. In response to the request 17, data 18 including a script 18 a that detects an update of the local storage 13 a and transmits update information 19 is transmitted to the browser 13. As a result, the local storage 13a and the local storage 14a can be synchronized via the local storage synchronization apparatus 10.

  At this time, the request 17 is generated by the script 16a so that the data 16 and the data 18 are recognized as data relating to the same Web site. The data 18 is displayed simultaneously with the data 16 as a Web page different from the data 16. As a result, the browser 13 can transmit the request 17 without violating security restrictions. Further, the script 18 a can detect the update of the local storage 13 a performed based on the data 16. Therefore, the local storages 13a and 14a can be synchronized under the existing specifications and restrictions of the browsers 13 and 14 without modifying the browsers 13 and 14.

[Second Embodiment]
FIG. 2 illustrates an information processing system according to the second embodiment.
The information processing system according to the second embodiment is a client server type Web system that provides a user with a Web page that is a visual user interface. This information processing system includes a server device 21 and terminal devices 100, 100a, and 100b. The server device 21 and the terminal devices 100, 100a, 100b are connected to the network 20. The network 20 is a wide area network such as the Internet, for example.

  The server device 21 is a server computer that executes a Web server as a server application. When the server device 21 receives the HTTP request from the terminal devices 100, 100a, and 100b, the server device 21 generates an HTML file corresponding to the URL included in the HTTP request, and returns an HTTP response including the HTML file.

  The HTML file is described in accordance with the HTML5 standard established by W3C (World Wide Web Consortium). The HTML file may include a script executed by the terminal devices 100, 100a, and 100b. The HTML file may include a link to a script file describing the script.

  The terminal devices 100, 100a, and 100b are client computers that execute browsers as client applications. The terminal devices 100, 100a, and 100b transmit an HTTP request to the server device 21 in response to a user operation on the browser, and receive an HTTP response including an HTML file. The terminal devices 100, 100a, 100b display Web pages based on the received HTML file.

  When a script is included in the HTML file or the script file linked from the HTML file, the terminal devices 100, 100a, and 100b execute the acquired script to control the display of the Web page. A plurality of browsers can be installed in the terminal devices 100, 100a, 100b. The terminal device 100 is an example of the local storage synchronization device 10 according to the first embodiment.

Next, the configuration of the terminal devices 100, 100a, 100b will be described.
FIG. 3 is a block diagram illustrating a hardware example of the terminal device.
The terminal device 100 includes a CPU 101, a RAM 102, an HDD 103, an image signal processing unit 104, an input signal processing unit 105, a medium reader 106, and a communication interface 107. Each of the above units is connected to the bus 108.

  The CPU 101 is a processor including an arithmetic circuit that executes program instructions. The CPU 101 loads at least a part of the program and data stored in the HDD 103 into the RAM 102 and executes the program. The CPU 101 may include a plurality of processor cores, the terminal device 100 may include a plurality of processors, and the processes described below may be executed in parallel using a plurality of processors or processor cores. A set of processors (multiprocessor) may be called a “processor”.

  The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculations. Note that the terminal device 100 may include a type of memory other than the RAM, or may include a plurality of memories.

  The HDD 103 is a non-volatile storage device that stores an OS (Operating System), software programs such as middleware and application software, and data. The program includes a local storage synchronization program. The terminal device 100 may include other types of storage devices such as a flash memory and an SSD (Solid State Drive), and may include a plurality of nonvolatile storage devices.

  The image signal processing unit 104 outputs an image to the display 111 connected to the terminal device 100 in accordance with a command from the CPU 101. As the display 111, a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD), a plasma display panel (PDP), an organic electro-luminescence (OEL) display, or the like can be used. .

  The input signal processing unit 105 acquires an input signal from the input device 112 connected to the terminal device 100 and outputs it to the CPU 101. As the input device 112, a mouse, a touch panel, a touch pad, a pointing device such as a trackball, a keyboard, a remote controller, a button switch, or the like can be used. A plurality of types of input devices may be connected to the terminal device 100.

  The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 113. Examples of the recording medium 113 include a magnetic disk such as a flexible disk (FD) and an HDD, an optical disk such as a CD (Compact Disc) and a DVD (Digital Versatile Disc), a magneto-optical disk (MO), A semiconductor memory or the like can be used. The medium reader 106 stores, for example, a program or data read from the recording medium 113 in the RAM 102 or the HDD 103.

  The communication interface 107 is connected to the network 20 and communicates with the server device 21. The communication interface 107 may be a wired communication interface connected to a communication device such as a switch by a cable, or may be a wireless communication interface connected to a base station or an access point by a wireless link.

  However, the terminal device 100 may not include the medium reader 106. Further, the display 111 and the input device 112 may be formed integrally with the casing of the terminal device 100. The terminal devices 100a and 100b and the server device 21 can also be realized using the same hardware as the terminal device 100. The CPU 101 is an example of the control unit 12 according to the first embodiment. The communication interface 107 is an example of the communication unit 11.

FIG. 4 is a block diagram illustrating an example of functions of the terminal device.
The terminal device 100 includes browsers 120 and 130, local storages 124 and 134, a proxy server 140, and a synchronization data storage unit 144. The local storages 124 and 134 and the synchronous data storage unit 144 can be realized as storage areas secured in the HDD 103. The browsers 120 and 130 and the proxy server 140 can be realized as program modules executed by the CPU 101. The terminal devices 100a and 100b can also be realized by the same module configuration as the terminal device 100.

  Browsers 120 and 130 are different types of Web browsers. At least one of the browsers 120 and 130 may be installed in the terminal device 100 by the user. The “different types of Web browsers” mentioned here include Web browsers with different brand names and different versions of Web browsers with the same brand name.

  The browser 120 includes a UI (User Interface) control unit 121, a script execution unit 122, and a communication unit 123. The browser 130 includes a UI control unit 131, a script execution unit 132, and a communication unit 133. The functions of the UI control unit 131, the script execution unit 132, and the communication unit 133 are the same as the functions of the module of the same name in the browser 120, and thus description thereof is omitted.

  The UI control unit 121 controls a Web page as a visual user interface. When acquiring the HTML file, the UI control unit 121 draws (renders) a Web page based on the description of the HTML file. The UI control unit 121 can simultaneously display a plurality of Web pages on the display 111 using a plurality of windows (may be a plurality of tabs). Further, the UI control unit 121 detects a user operation. User operations include inputting a URL, clicking a hyperlink in a Web page, inputting data in an input field (field) in the Web page, and the like.

  If the script is included in the acquired HTML file or a script file linked from the HTML file, the script execution unit 122 executes the script. The script is, for example, source code written in a high-level language.

  Processing that can be executed by the script includes transmission of an HTTP request. It is also possible to display a Web page obtained in response to the transmitted HTTP request by starting a new window (which may be a new tab). However, from the viewpoint of security, the access destinations that can be specified by a script are limited to those having the same origin as the script. “Origin” is a set of protocol scheme, host name, and port number. The URL is http: // www. a **. com / index. For html, the protocol scheme is http and the host name is www. a **. and the port number is 80 (when the port number is 80, the description can be omitted).

  Further, processing that can be executed by a script includes communication using a Web socket. When using a Web socket, a connection is first established with a communication partner. When the connection is established, a message can be transmitted bidirectionally between the browser 120 and the communication partner. By using a Web socket, “push-type communication” from the server side to the browser 120 can be realized unlike HTTP communication.

  Further, the process executable by the script includes access to the local storage 124 corresponding to the browser 120, as will be described later. The script can write data to the local storage 124 and read data from the local storage 124. However, from the viewpoint of security, data that can be read by a script is limited to data written by the script itself or by another script having the same script and origin.

  The communication unit 123 transmits an HTTP request in response to a user operation or script instruction detected by the UI control unit 121. In addition, the communication unit 123 receives an HTTP response to the transmitted HTTP request. In the second embodiment, the communication unit 123 is set to transmit an HTTP request to the proxy server 140. The HTTP response is received from the proxy server 140. The communication unit 123 transmits and receives Web socket messages in response to instructions from the script.

  The local storage 124 is a non-volatile storage area provided corresponding to the browser 120. The local storage 124 stores data in a key-value format divided for each origin. For example, about 10 MB of data can be stored for one origin. The script execution unit 122 can write the key and value (value) in the local storage 124 in association with each other. Further, the script execution unit 122 can read a value from the local storage 124 by designating a key. Data relating to one origin stored in the local storage 124 can be referred to only when a script belonging to the origin is executed in the script execution unit 122.

  The local storage 134 is a non-volatile storage area provided corresponding to the browser 130. Similar to the local storage 124, the local storage 134 stores data in a key-value format by dividing it for each origin. Data regarding one origin stored in the local storage 134 can be referred to only when a script belonging to the origin is executed in the script execution unit 132.

  The proxy server 140 relays HTTP communication between the browsers 120 and 130 and the server device 21. The proxy server 140 includes an access transfer unit 141, a control page generation unit 142, and a data synchronization unit 143.

  When receiving an HTTP request from the browsers 120 and 130, the access transfer unit 141 determines whether a predetermined character string is included in a predetermined position of the HTTP request, that is, whether it is an HTTP request for control. Examples of the predetermined position include a path name included in the URL, a hash (characters below “#”) and a query (characters below “?”) Added to the end of the URL, and an HTTP request that is POST. Examples include the body.

  If it is not an HTTP request for control, the access transfer unit 141 transfers the HTTP request to the server device 21. When receiving the HTTP response including the HTML file from the server device 21, the access transfer unit 141 transfers the HTTP response to the browser (browser 120 or browser 130) that transmitted the HTTP request. However, the access transfer unit 141 may cache the HTML file acquired from the server device 21. When the HTML file corresponding to the URL specified by the browser 120 or 130 is in the cache, the access transfer unit 141 may return the cached HTML file without transferring the HTTP request to the server device 21. .

  In transmitting the HTTP response, the access transfer unit 141 determines whether the browser that transmitted the HTTP request is browsing the web page of the same origin, that is, whether it is the second or subsequent HTTP request for a certain web site. Whether the request is the second or later HTTP request can be determined by referring to an access information table described later. In the case of the first HTTP request, the access transfer unit 141 inserts a predetermined script into the acquired HTML file. This script causes the browsers 120 and 130 to transmit the above-described HTTP request for control.

  On the other hand, if the request is a control HTTP request, the access transfer unit 141 transfers the HTTP request to the control page generation unit 142 instead of transferring the HTTP request to the server device 21. The access transfer unit 141 receives an HTTP response including an HTML file from the control page generation unit 142, and transfers the HTTP response to the browser that transmitted the HTTP request. However, the HTTP request may be returned to the browser without going through the access transfer unit 141.

  When receiving the HTTP request from the access transfer unit 141, the control page generation unit 142 generates an HTML file for displaying the control page, and transmits an HTTP response including the HTML file to the access transfer unit 141. This HTML file may be prepared in advance and stored in the HDD 103. The control page is a control Web page in which a script that enables the local storages 124 and 134 to be synchronized between the browsers 120 and 130 is described. The control page can also be called a synchronization page.

  The URL of the control page includes the same origin as the original web page that called the control page. Therefore, the browsers 120 and 130 recognize that the control page and the original Web page have the same origin. According to the HTML5 specification, a script of a certain web page can detect an update of local storage that has occurred in another web page having the same origin. However, the specification of HTML5 does not guarantee that the update of the local storage that occurs in the same Web page can be detected. Therefore, in the second embodiment, a control page having the same origin is prepared separately from the original Web page.

  In browsers 120 and 130, the control page is displayed in a window (may be a separate tab) different from the original Web page. The control page only needs to include a script for synchronizing the local storages 124 and 134, and does not have to include characters and images to be displayed. The window for displaying the control page may be arranged on the screen with a sufficiently small size compared to the original Web page so that the window is not easily recognized by the user.

  The data synchronization unit 143 establishes a Web socket connection with the browsers 120 and 130. Connection establishment is executed in response to a request from the browsers 120 and 130 according to a script included in the control page. The data synchronization unit 143 realizes synchronization of the local storages 124 and 134 using the established connection. It is also possible to use HTTP communication instead of communication using a Web socket.

  When the browser 120 updates the local storage 124, the data synchronization unit 143 receives an update notification from the browser 120. The update notification is transmitted from the browser 120 according to the script included in the control page. The data synchronization unit 143 stores the key value format data (update contents) included in the update notification in the synchronization data storage unit 144. Further, the data synchronization unit 143 determines whether the browser 130 is displaying a Web page with the same origin. Whether a web page with the same origin is being displayed can be determined by referring to an access information table described later. However, the data synchronization unit 143 may check whether the Web page of the same origin is being displayed by transmitting a Web socket message to the browser 130 periodically or when receiving an update notification. Good.

  If the browser 130 is displaying the same origin web page when the update notification is received, the data synchronization unit 143 transmits a push-type message including the update notification to the browser 130 using the web socket. The transmitted message is processed by a script included in the control page displayed on the browser 130. The local storage 134 is updated based on the update notification according to the script. On the other hand, when the update notification is received and the web page of the same origin is not displayed on the browser 130, the data synchronization unit 143 waits for the browser 130 to display the web page of the same origin.

  When the control page is displayed on the browser 130, the data synchronization unit 143 receives a message including data stored in the local storage 134 from the browser 130. This message is transmitted from the browser 130 according to the script included in the control page. The data synchronization unit 143 compares the data received from the browser 130 with the data stored in the synchronization data storage unit 144, and generates difference data indicating the difference between the two. The data synchronization unit 143 transmits a push-type message including the generated difference data to the browser 130 using a Web socket. The transmitted message is processed by a script included in the control page displayed on the browser 130. The difference data is stored in the local storage 134 according to the script.

  The synchronous data storage unit 144 stores key-value format data. The synchronous data storage unit 144 is a storage area managed by the proxy server 140 and is provided separately from the local storages 124 and 134. When the synchronization of the local storages 124 and 134 is completed, the data stored in the synchronization data storage unit 144 is the same as the local storages 124 and 134. When one of the local storages 124 and 134 is updated, the updated content is reflected in the synchronous data storage unit 144. By referring to the synchronous data storage unit 144, the local storages 124 and 134 can be synchronized later. The synchronous data storage unit 144 stores an access information table to be described later.

FIG. 5 is a diagram illustrating an example of the synchronization data table.
The synchronization data table 145 is stored in the synchronization data storage unit 144. The synchronization data table 145 has items of origin, key, and value. The key is a character string that identifies key-value format data. Keys do not overlap within an origin. The value is a character string associated with the key. In the origin item, a character string indicating the origin (protocol scheme, host name, and port number) of a script in which a key / value pair is written is registered. A plurality of key / value pairs can be registered for one origin.

  The local storages 124 and 134 can also be realized by the same data structure as the synchronous data table 145. Note that the capacity of data that can be stored in the local storages 124 and 134 is set in advance for one origin. For example, the capacity of the local storages 124 and 134 for each origin is set to about 10 MB.

FIG. 6 is a diagram illustrating an example of the access information table.
The access information table 146 is stored in the synchronous data storage unit 144. The access information table 146 has items of a browser and an origin. In the browser item, the identification names of the browsers 120 and 130 are registered. The identification name may include the brand name and version number of the browsers 120 and 130. For example, the identification name of the browser 120 is “Browser A”, and the identification name of the browser 130 is “Browser B”. In the origin item, the origin of the Web site being accessed by the browsers 120 and 130 is registered.

  In the example of the access information table 146 illustrated in FIG. 6, the browser 120 uses http: // www. a **. com / and URL: http: // host. b **. This indicates that a Web page with a URL including org / is being displayed. Further, in the example of the access information table 146 shown in FIG. 6, the browser 130 has http: // www. a **. com / and URL: http: // www. c **. This indicates that a Web page with a URL including com / is being displayed.

  When the access transfer unit 141 receives an HTTP request designating a URL including a certain origin, the access transfer unit 141 registers the origin in the access information table 146. The origin registered in the access information table 146 may be deleted from the access information table 146 after a predetermined time has elapsed since registration. Further, it may be detected that a certain browser has closed or terminated a window, and when detected, the origin corresponding to the browser may be deleted from the access information table 146.

Next, the flow of processing for synchronizing the local storages 124 and 134 will be described.
FIG. 7 is a sequence diagram illustrating an example of Web access.
The browser 120 detects that a URL is input or a hyperlink that specifies the URL is clicked by a user operation. Then, the browser 120 transmits an HTTP request (Web page request) including the URL to the proxy server 140 (S10). The proxy server 140 transfers the web page request to the server device 21 (S11). The server device 21 generates an HTML file of the Web page corresponding to the specified URL, and transmits an HTTP response including the HTML file to the proxy server 140 (S12). The proxy server 140 adds a script to the HTML file of the Web page and transfers it to the browser 120 (S13).

  The browser 120 transmits a control HTTP request (control page request) to the proxy server 140 by executing the script included in the Web page in step S13 (S14). In the control page request, the same origin as the Web page request in step S10 and a URL including a predetermined character string are specified. In response to the control page request, the proxy server 140 generates an HTML file for the control page, and transmits an HTTP response including the HTML file for the control page to the browser 120 (S15). One control page is displayed for each origin in the browser 120.

  The browser 120 establishes a Web socket connection with the proxy server 140 by executing the script included in the control page in step S15. Further, the browser 120 extracts data related to the origin of the control page in step S15 from the local storage 124. Then, the browser 120 transmits a message (synchronization request) including the character string indicating the origin and the extracted data to the proxy server 140 using the Web socket connection (S16).

  The proxy server 140 searches the synchronization data storage unit 144 for data related to the origin indicated by the synchronization request. The proxy server 140 compares the retrieved data with the data included in the synchronization request, and generates difference data indicating the difference between the two. Then, the proxy server 140 transmits a message including the difference data to the browser 120 using the Web socket connection (S17). The browser 120 stores the difference data received from the proxy server 140 in the local storage 124. Thereby, the local storages 124 and 134 are synchronized with respect to the origin of the Web page in step S13 (S18).

  The browser 120 detects that the local storage 124 has been updated on the Web page in step S13 by executing a script included in the control page in step S15 (S19). The script for updating the local storage 124 is originally described in the HTML file acquired from the server device 21 in step S12. When the update of the local storage 124 is detected, the browser 120 transmits a message (update notification) including the character string indicating the origin of the Web page in Step S13 and the update data to the proxy server 140 using the Web socket connection ( S20).

  The proxy server 140 stores the data included in the update notification in the synchronous data storage unit 144 as data about the origin specified in the update notification. Here, it is assumed that the browser 130 is being executed in the terminal device 100, and the Web page having the same origin as the Web page in step S13 is displayed. In this case, a Web socket connection is established between the browser 130 and the proxy server 140 as in step S16. Then, the proxy server 140 transmits an update notification to the browser 130 using the Web socket connection (S21). The browser 130 stores the data indicated by the update notification received from the proxy server 140 in the local storage 134 in accordance with the script included in the control page. Thereby, the local storages 124 and 134 are synchronized with respect to the origin of the Web page in step S13 (S22).

FIG. 8 is a diagram illustrating an example of a script added to a Web page.
For example, the HTML file 31 is transmitted from the proxy server 140 to the browser 120 in step S13 described above. The script of the HTML file 31 includes a function openSyncPage () and a function storageUpdate ().

  The function openSyncPage () is inserted into the HTML file 31 by the proxy server 140. The function openSyncPage () is automatically executed when a Web page based on the HTML file 31 is displayed. The function openSyncPage () generates a URL in which a predetermined path name (for example, /Sync/syncPage.html) is linked to the origin of the HTML file 31. The HTML file indicated by this path name may not exist in the server device 21. In that case, it can be said that this URL is a virtual URL. The function openSyncPage () displays the Web page corresponding to the generated URL in a new window (which may be a new tab) different from the Web page based on the HTML file 31.

  The function storageUpdate () is originally described in the HTML file acquired from the server device 21. The function storageUpdate () stores a key / value pair in the local storage 124.

FIG. 9 is a diagram illustrating an example of a script included in the control page.
For example, the HTML file 32 is transmitted from the proxy server 140 to the browser 120 in step S15 described above. The script of the HTML file 32 includes a variable ws, a synchronization request process, a message reception process, a function updateIStorage (), an event listener registration process, and a function sendEventData ().

  A variable ws indicates a Web socket connection established with the proxy server 140. When the control page is displayed, a web socket connection is established. In the synchronization request process, all data that can be recognized from the script of the HTML file 32 (data regarding the origin of the HTML file 32) is extracted from the local storage 124. In the synchronization request process, a message including the symbol “0”, a character string indicating the origin, and the extracted data is transmitted using the Web socket connection. The symbol “0” is a symbol for identifying that the message to be transmitted is a synchronization request.

  In the message reception process, it is determined whether a Web socket message is received, and when the Web socket message is received, the function updateISstorage () is called. The function updateIStorage () stores the key / value pair included in the received Web socket message in the local storage 124.

  The event listener registration process is executed when the control page is displayed. The event listener registration processing is set so that event information including the written data can be acquired when data related to the same origin as the HTML file 32 is written to the local storage 124. The event listener registration process is set so that the function sendEventData () is called when event information is acquired. The function sendEventData () transmits a message including the symbol “1”, a character string indicating the origin, and the acquired event information using the connection of the Web socket. The symbol “1” is a symbol for identifying that the message to be transmitted is an update notification.

FIG. 10 is a flowchart illustrating an exemplary procedure of proxy transfer processing.
This proxy transfer process is executed by the proxy server 140. Here, it is assumed that communication is performed between the browser 120 and the proxy server 140. Similar communication is performed between the browser 130 and the proxy server 140.

(S30) The access transfer unit 141 receives an HTTP request.
(S31) The access transfer unit 141 determines whether the HTTP request received in step S30 is a control page request. Whether the request is a control page request can be determined, for example, based on whether a predetermined path name is included in the URL. Further, for example, it can also be determined based on whether a predetermined hash or query is included in the URL or whether the HTTP request type is POST and the body includes a predetermined character string. If the request is a control page request, the process proceeds to step S37; otherwise, the process proceeds to step S32.

  (S32) The access transfer unit 141 transfers the received HTTP request to the server device 21. The access transfer unit 141 receives an HTTP response including an HTML file as a response to the transferred HTTP request.

  (S33) The access transfer unit 141 determines whether the browser 120 has already accessed the website of the same origin as the HTML file acquired in step S32. Specifically, the access transfer unit 141 determines whether the origin of the acquired HTML file is registered in the access information table 146 in association with the browser 120. If registered, the process proceeds to step S36, and if not registered, the process proceeds to step S34. Note that the origin of the access information table 146 may be deleted as the fixed time elapses, the control page is closed, the browser 120 is terminated, and the like.

(S34) The access transfer unit 141 registers the origin of the acquired HTML file in the access information table 146 in association with the browser 120.
(S35) The access transfer unit 141 adds a predetermined script to the acquired HTML file. The script to be added designates a URL including the same origin as the HTML file acquired in step S32, and indicates a process of generating an HTTP request including a predetermined character string. The script to be added is, for example, the function openSyncPage () included in the HTML file 31 shown in FIG.

  (S36) The access transfer unit 141 transfers the HTTP response received from the server device 21 to the browser 120. However, a predetermined script may be added to the HTML file included in the HTTP response by the above step S35.

  (S37) The access transfer unit 141 transfers the HTTP request to the control page generation unit 142. The control page generation unit 142 generates an HTML file indicating the control page, and transmits an HTTP response including the generated HTML file to the access transfer unit 141. The access transfer unit 141 transfers the HTTP response received from the control page generation unit 142 to the browser 120. The HTML file of the control page includes a script indicating processing related to the synchronization of the local storages 124 and 134.

  This script indicates a process of establishing a Web socket connection with the proxy server 140 when the control page is displayed. In addition, this script indicates a process of transmitting a synchronization request to the proxy server 140 via a Web socket when a control page is displayed, receiving difference data from the proxy server 140, and updating the local storage 124. Further, this script indicates a process of detecting that the local storage 124 has been updated by a script of another Web page having the same origin as the control page, and transmitting an update notification to the proxy server 140 by using a Web socket. In addition, this script indicates a process of receiving an update notification from the proxy server 140 via a Web socket and updating the local storage 124 based on the received update notification.

FIG. 11 is a flowchart illustrating an exemplary procedure of proxy synchronization processing.
This proxy transfer process is executed by the proxy server 140. Here, it is assumed that communication is performed between the browser 120 and the proxy server 140. Similar communication is performed between the browser 130 and the proxy server 140.

(S40) The data synchronization unit 143 receives the Web socket message.
(S41) The data synchronization unit 143 determines whether the message received in step S40 is a synchronization request. Whether a message is a synchronization request can be determined, for example, by confirming that the symbol included in the head of the message is “0”. If the message is a synchronization request, the process proceeds to step S42. If the message is not a synchronization request, that is, if the message is an update notification, the process proceeds to step S44. Note that, for example, the symbol “1” is included in the head of the message indicating the update notification.

  (S42) The data synchronization unit 143 extracts a character string and data indicating the origin from the message received in step S40. The data synchronization unit 143 retrieves all data corresponding to the origin specified by the message from the synchronization data table 145 stored in the synchronization data storage unit 144. Then, the data synchronization unit 143 compares the data retrieved from the synchronization data table 145 with the data extracted from the message, and generates difference data.

  For example, when there is a key that is included in the synchronization data table 145 but not included in the message, the data synchronization unit 143 inserts a set of the key in the synchronization data table 145 and a value corresponding to the key into the difference data. This indicates that the key / value pair is added to the local storage 124. In addition, when the same key exists and the value corresponding to the key is different between the synchronous data table 145 and the message, the data synchronization unit 143 determines the set of the key and the value in the synchronous data table 145 corresponding thereto. Insert into differential data. This indicates that the value in the local storage 124 corresponding to the key is overwritten. Further, when there is a key included in the message that is not included in the synchronization data table 145, the data synchronization unit 143 inserts a set of the key and an empty character string into the difference data. This indicates that the key / value pair is deleted from the local storage 124.

(S43) The data synchronization unit 143 transmits a message including the difference data generated in step S42 to the browser 120 via the Web socket.
(S44) The data synchronization unit 143 extracts a character string and data indicating the origin from the message received in step S40. The data synchronization unit 143 stores the extracted data in the synchronization data table 145 in association with the origin specified by the message.

  For example, if the key included in the message does not exist in the synchronization data table 145, the data synchronization unit 143 adds the key / value pair to the synchronization data table 145. If the same key exists and the value is different between the message and the synchronization data table 145, the data synchronization unit 143 overwrites the value corresponding to the key stored in the synchronization data table 145. When the message includes a key / null character string pair, the data synchronization unit 143 deletes the key / value pair from the synchronization data table 145.

  (S45) The data synchronization unit 143 determines whether there is another browser (browser 130) that is accessing the website of the same origin. Whether or not there is another corresponding browser can be determined, for example, by associating with the other browser and determining whether the origin specified in the message is registered in the access information table 146. However, the data synchronization unit 143 may periodically send a Web socket message to another browser (browser 130) to check whether a control page related to the same origin is displayed. Further, when the data synchronization unit 143 receives an update notification message, the data synchronization unit 143 may confirm the message by transmitting a Web socket message to another browser. If there is another corresponding browser, the process proceeds to step S46, and if there is not, the process ends.

(S46) The data synchronization unit 143 transmits a message indicating an update notification through a Web socket to another browser (browser 130) corresponding to step S45.
FIG. 12 is a flowchart illustrating an exemplary procedure of browser access processing.

This browser access process is executed by the browser 120. The browser 130 can perform the same processing as the browser 120.
(S50) The communication unit 123 transmits an HTTP request to the proxy server 140.

  (S51) The communication unit 123 receives an HTTP response including an HTML file from the proxy server 140. The UI control unit 121 performs rendering based on the acquired HTML file, and displays a Web page in a certain window (which may be a tab).

  (S52) The script execution unit 122 executes the script included in the HTML file acquired in step S51. Here, the script execution unit 122 designates a URL including the same origin as the acquired HTML file, and generates an HTTP request including a predetermined character string. The communication unit 123 transmits the HTTP request generated by the script execution unit 122 to the proxy server 140. This HTTP request corresponds to a control page request for acquiring an HTML file indicating a control page.

  (S53) The communication unit 123 receives an HTTP response including an HTML file from the proxy server 140 as a response to the HTTP request transmitted in step S52. The UI control unit 121 activates a new window (may be a new tab) that is different from the window in which the Web page in step S51 is displayed. Then, the UI control unit 121 performs rendering based on the acquired HTML file and displays a control page in a new window. However, the control page may not include characters or images.

  (S54) The script execution unit 122 executes the script included in the HTML file acquired in step S53. Here, the script execution unit 122 instructs the communication unit 123 to establish a web socket connection with the proxy server 140. The communication unit 123 establishes a Web socket connection according to the instruction.

  (S55) The script execution unit 122 extracts all data from the local storage 124 that has the same origin as the HTML file acquired in step S53 (that is, the same origin as the HTML file acquired in step S51).

  (S56) The script execution unit 122 generates a synchronization request including the symbol “0” indicating the type of message, the character string indicating the origin of the HTML file acquired in step S53, and the data extracted in step S55. The communication unit 123 transmits a synchronization request to the proxy server 140 using the Web socket connection established in step S54.

  (S57) The communication unit 123 receives a message including difference data from the proxy server 140 using the Web socket connection established in step S54. The script execution unit 122 detects that a Web socket message has been received, and stores the difference data included in the message in the local storage 124.

  For example, if the key included in the difference data does not exist in the local storage 124, the script execution unit 122 adds the key / value pair to the local storage 124. Further, when the same key exists and the value is different between the difference data and the local storage 124, the script execution unit 122 overwrites the value corresponding to the key stored in the local storage 124. Further, when the difference data includes a key / null character string pair, the script execution unit 122 deletes the key / value pair from the local storage 124.

FIG. 13 is a flowchart illustrating a procedure example of browser synchronization processing.
This browser access process is repeatedly executed by the browser 120. The browser 130 can perform the same processing as the browser 120.

  (S60) The script execution unit 122 monitors event information related to the local storage 124 according to the script included in the HTML file acquired in step S53 described above. When the local storage 124 is updated by another web page having the same origin as the control page, event information including the updated data is acquired. The script execution unit 122 determines whether event information related to the local storage 124 has been acquired. If event information related to the local storage 124 is acquired, the process proceeds to step S61. If not acquired, the process proceeds to step S62.

  (S61) The script execution unit 122 extracts updated data from the event information. The script execution unit 122 generates an update notification including the symbol “1” indicating the type of message, the character string indicating the origin of the HTML file acquired in step S53, and the extracted data. The communication unit 123 transmits an update notification to the proxy server 140 using the Web socket connection established in step S54 described above.

  (S62) The script execution unit 122 determines whether a Web socket message is received from the proxy server 140. If a message is received, the process proceeds to step S63, and if not received, the process ends.

(S63) The script execution unit 122 updates the local storage 124 based on the message received in step S62.
For example, if the key included in the message does not exist in the local storage 124, the script execution unit 122 adds the key / value pair to the local storage 124. If the same key exists and the value is different between the message and the local storage 124, the script execution unit 122 overwrites the value corresponding to the key stored in the local storage 124. When the message includes a key / null character string pair, the script execution unit 122 deletes the key / value pair from the local storage 124.

  According to the information processing system of the second embodiment, the local storage 124 of the browser 120 and the local storage 134 of the browser 130 can be synchronized via the proxy server 140. Thereby, even if it is a case where the same Web site is accessed using browser 120,130, it can suppress that the old data which the user input previously is not intentionally uploaded to the server apparatus 21. FIG. Therefore, it is possible to suppress the deletion of new data input by the user, and it is possible to suppress the release of old data that is not desired to be disclosed against the user's intention.

  In the HTTP request for calling the control page from the original Web page, a URL including the same origin as the original Web page is specified. This allows the HTTP request to be transmitted by the script even under the security restrictions of the browsers 120 and 130. In addition, the browsers 120 and 130 recognize that the origin of the original Web page and the control page is the same. Thereby, the update of the local storage by the original Web page can be detected under the specification of HTML5. Further, even under the security restrictions of the browsers 120 and 130, local storage data relating to the same origin as the original Web page can be handled by the script of the control page.

  As described above, the local storages 124 and 134 can be synchronized even under the HTML5 specifications and the security restrictions of the browsers 120 and 130. Therefore, it is not necessary to modify the existing browsers 120 and 130, and the synchronization of the local storages 124 and 134 can be easily realized. Further, the security of the browsers 120 and 130 can be maintained.

  The information processing according to the first embodiment can be realized by causing the local storage synchronization apparatus 10 to execute a program. The information processing according to the second embodiment can be realized by causing the server device 21 and the terminal devices 100, 100a, and 100b to execute a program.

  The program can be recorded on a computer-readable recording medium (for example, the recording medium 113). As the recording medium, for example, a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like can be used. Magnetic disks include FD and HDD. Optical discs include CD, CD-R (Recordable) / RW (Rewritable), DVD, and DVD-R / RW. The program may be recorded and distributed on a portable recording medium. In this case, the program may be copied from a portable recording medium to another recording medium such as an HDD (for example, the HDD 103) and executed.

2 server 10 local storage synchronization device 11 communication unit 12 control unit 13, 14 browser 13a, 14a local storage 15, 17 request 16, 18 data 16a, 18a script 19 update information

Claims (7)

A local storage synchronization method performed by a computer,
Receive a request addressed to the server from the first browser using local storage,
Inserting a script indicating a process for transmitting another request into the data corresponding to the request acquired from the server and transmitting the data to the first browser;
Receiving the other request from the first browser;
In response to the other request, other data including another script indicating processing for detecting update of the local storage and transmitting update information is transmitted to the first browser,
Receiving the update information from the first browser;
Sending the update information to the second browser when a second browser using another local storage is running;
Local storage synchronization method. The received update information is stored in a storage area different from the local storage and the other local storage,
If the second browser is not executed when the update information is received, the update information stored in the storage area is transmitted after the second browser is started.
The local storage synchronization method according to claim 1. The script further shows a process of displaying the other data received in response to the other request in a window different from the data.
The local storage synchronization method according to claim 1 or 2. The other script further shows a process of updating the local storage when receiving other update information according to the update of the other local storage.
The local storage synchronization method according to any one of claims 1 to 3. The first browser and the second browser are executed on the computer;
The local storage synchronization method according to any one of claims 1 to 4. A communication unit that communicates with the server;
A control unit that controls access to the server from a first browser that uses local storage and a second browser that uses other local storage;
And the control unit includes:
Receiving a request addressed to the server from the first browser;
Inserting a script indicating a process for transmitting another request into the data corresponding to the request acquired from the server and transmitting the data to the first browser;
Receiving the other request from the first browser;
In response to the other request, other data including another script indicating processing for detecting update of the local storage and transmitting update information is transmitted to the first browser,
Receiving the update information from the first browser;
Sending the update information to the second browser when the second browser is running;
Local storage synchronizer. On the computer,
Receive a request addressed to the server from the first browser using local storage,
Inserting a script indicating a process for transmitting another request into the data corresponding to the request acquired from the server and transmitting the data to the first browser;
Receiving the other request from the first browser;
In response to the other request, other data including another script indicating processing for detecting update of the local storage and transmitting update information is transmitted to the first browser,
Receiving the update information from the first browser;
Sending the update information to the second browser when a second browser using another local storage is running;
A local storage synchronization program that executes processing.

Images