HTML5 Project Note 7: Using the HTML5 WebStorage API to build a session mechanism that corresponds to. net

HTML5 's web Storage API, also known as the Domstarage API, is used to persist data between Web requests. Before the advent of the Web Starage API, we were storing the interaction data between the client and the server on the remote servers, and with the advent of the Web Starage API, we could store the interactive data we repeatedly accessed on the client side, when the user opened the browser, Can quickly read to the data, reduce the user wait, data traffic.

Before the advent of the Web starage, we generally used cookies to store data on the client side, to save the session identifiers between the client and the server, and to keep the local personalization data in the application. A cookie is limited to a storage size of only 4KB, and it is impossible to store big data; The cookie transparently transmits data in the server and browser in the case of a request, and the data is at a security risk without encryption.

In contrast, the Web starage API uses Jsvascript to save objects, load them in pages, read and save data, and store data that is not transmitted over the network, and can hold up to a few megabytes of data. is undoubtedly a weapon of temporary storage of our client data.

Browser support Scenarios

Browser type	Version number
Chrome	Version 3.0 and above
FireFox	Version 3.0 and above
Internet Explorer	Version 8.0 and above
Ppera	Version 10.5 and above
Safari	Version 4.0 and above

To manipulate data using Sessionstorage:

Setting Data:

Window.sessionStorage.setItem ("UserName", "Ben"); Or

Window.sessionStorage.UserName = "Ben";

Get Data:

var UserName = Window.sessionStorage.getItem ("UserName"); Or

var UserName = Window.sessionStorage.UserName;

Delete data:

Window.sessionStorage.removeItem ("UserName");

To clear the data:

Window.sessionStorage.clear ();

Sessionstorage life cycle values exist in the browser window or page labels, and once you close the browser or page label, the data is lost, so it should be considered a session ID between pages.

Data isolation, different browser pages or tags, the data will be saved across pages, but will not be leaked.

To set or get data using Localstorage:

Setting Data:

Window.localStorage.setItem ("UserName", "Ben"); Or

Window.localStorage.UserName = "Ben";

Get Data:

var UserName = Window.localStorage.getItem ("UserName"); Or

var UserName = Window.localStorage.UserName;

Delete data:

Window.localStorage.removeItem ("UserName");

To clear the data:

Window.localStorage.clear ();

comparison of Sessionstorage and Localstorage:

Sessionstorage	Localstorage
Data is saved until the window or tab page that stores it is closed	The life cycle of the data is longer than the life cycle of the window or browser
The data is only valid in the window that builds it or the Javelin page	Data can be shared between Windows and tabs of the same origin

From above, the visible localstorage has a longer life cycle and a wider storage range that can be used for data storage and sharing between multiple browser windows and tabbed pages or multiple views.

Build with. NET corresponds to the session mechanism:

When our HTML5 client application is to be docked with a. NET daemon, it is necessary to construct a corresponding session mechanism to achieve a consistent operation:

Let's take a look at the session mechanism of. NET, which is created by the server, assigns a SessionID, and then "tells" the client, and the client sends the session message to the HTTP header each time it accesses, There is a session list on the server, which contains all the information about the session, including the timeout information of the session.

In the previous version of IE6:

Open IE to login an account a. Call this IE IE1.
Re-open an IE from the desktop. Login Account B. This IE is the session of the B account. This IE is called IE2
IE1 and IE2 record the session is not the same. The session between the sessions does not affect.

This label browser after IE7. An IE opens all the tabs, even opening multiple IE is a shared session.
Continue with the above operation. We use IE1 's menu bar "file"-"New"-"window" to create a new ie, called him IE3. Because IE3 is from the IE1. So IE3 inherited the session of IE1. When you log in to account C with IE3. IE1, IE3 of the session are account C ... Then use IE1 to login the account D. IE1, IE3 login account session becomes the session of account D.

When Google Chrome opens all its tabs or opens multiple chrome, it is shared with a session, which is determined by the timeout of session time and the end of the entire application's life.

This rule determines the same same machine on the same-origin browser is not able to operate multiple users at the same time the program. Here is the same-origin browser, that is, you open an application with IE, with chrome open an application, their session is isolated, no contact.

We do a test here, build two ASPX pages in the project, one page is pageone.aspx, and one page is

Pagetwo.aspx, they use the same session,session["UserName"

, the value for saving session["UserName" in the Pageone page is Ben:

The Pagetwo page also shows Ben:

So the offline system also adopted the same strategy: using Localstorage processing session mechanism

Localstorage

The life cycle of the data is longer than the life cycle of the window or browser

Data can be shared by each window, label page, or browser that is open at the same time

So we use the Localstorage recording session mechanism to monitor the change of the session with the HTML5 storage event:

1, log the session when the user logs in:

Window.localStorage.setItem ("Sessionmechanism", username);

2. Set up event monitoring on other form pages:

Window.addeventlistener ("Storage", checkstorageevent, True);

function Checkstorageevent (e) {

if (E.key = = "Sessionmechanism") {

Alert ("Login timed out!") , account "+ E.newvalue +" is logged in! ");

Window.location.href = ". /login.htm ";

}

}

Once a second user logs in, whether it's a different tab in the same browser or a different browser window, the previous user will time out and return to the login page ...

This ensures that we in the same-origin browser can only have one account in the login operation, if other users logged in, the current user will be forced offline. This avoids errors caused by user inconsistencies at the front and back, and we will then talk about cross-domain communication, offline systems and online systems interaction, so online and offline login users must remain consistent.

Here we apply this session mechanism to our system:

Now make a scene, on this side of our login page to record the global localstorage, once the login successfully logged the current user, so on the login.htm page has such a piece of code:

Window.localStorage.setItem ("Sessionmechanism", username);

After the login is successful, we have reached our user Information page:

At the same time, our localstorage has this key value pair:

Then we sign in to another account on the login page brand users:

On the User Information page, the following dialog box pops up and jumps to the login page:

This ensures that only one user of the same origin browser is performing the operation.

HTML5 Project Note 7: Using the HTML5 WebStorage API to build a session mechanism that corresponds to. net