Javascript session variables without cookies
- Transfer
Moreover, the browser adds cookies to the request header - and since many corporate firewalls only allow headers to a certain size, your pages may not load at all (I saw that’s awful).
Therefore, I wrote a small script that will allow you to use session variables in Javascript without installing cookies. It allows you to store up to 2 MB of data, which is much less limited in capabilities than a cookie-based solution.
Insert sessvars.js (6 Kb) to the head section of the page where you want to use session variables in front of other scripts that will use them.
How to use
You now have at your disposal an object called sessvars . It works like any other normal object in Javascript - you can add variables to it and change their values. The only difference is that sessvars will not disappear when going from page to page. That is, if your script does something like this:
sessvars.myObj = {name: "Thomas", age: 35}on one page, then you can access the sessvars.myObj object on any other page that the user will visit in the current session.
Try an example
Methods
The only property variable of the sessvars object that you should not touch is $ , because it contains a number of useful methods:
- sessvars. $. clearMem ()
Clears sessvars - sessvars. $. usedMem ()
Returns the amount of memory used in kilobytes - sessvars. $. usedMemPercent ()
Returns the amount of used memory as a percentage of the total possible amount - sessvars. $. debug ()
Displays the debug window at the top of the page (as in the example above) - sessvars. $. flush ()
Explicitly saves the current state of sessvars, so that all data will be saved when you go to another page. This is rarely necessary, since in a normal situation this is done automatically during the unload event.
Flags
There are also a number of different flags with which you can set the sessvars behavior :
- sessvars. $. prefs.memlimit
Default - 2000
Specifies the amount of data in KB allowed for storage in sessvars. The default is 2000 Kb, since Opera 9.25 has a limit just above this number. Other browsers (IE7.0, Firefox 1.5 / 2.0 and Safari 3.0) have a much higher restriction - 10 MB is not difficult for these browsers. - sessvars. $. prefs.autoFlush
true / false, default true true
Determines whether the flush () method will be called automatically - sessvars. $. prefs.crossDomain
true / false, default false
If the flag is set to true, the contents of sessvars can be read from different domains (if both sites use sessvars.js). - sessvars. $. prefs.includeFunctions
true / false, default false
Determines whether sessvars will save functions. - sessvars. $. prefs.includeProtos
true / false, default false
If true, the properties assigned to the prototypes of various data or objects will be saved. It is rarely necessary.
Where is the data stored?
The principle underlying sessvars.js is quite simple:
I used the fact that you can set the window.name property in javascript - this property is usually used to name windows and frames so that you can access them by name from scripts. In order not to overlap with this in the frameset (if someone still uses them), my script uses only the top.name property .
A great feature of window.name is that this value is preserved between page loads (and even domains) and that it allows you to store very long names. The unfortunate side is that the property only allows a string data type, so I used the JSON stringifierto serialize / deserialize data.
And finally, I added a window unload event handler that removes the need to manually save data every time you change something in sessvars.
Security questions
There is a flag in sessvars for use between domains, but although its default value is false, it only ensures that you do not get garbage by mistake from the window.name property from other sites. In fact, the data will be completely accessible to other scripts on other sites, and anyone can make javascript: alert (window.name) in the address bar of the browser.
Therefore, please do not store important information in sessvars, such as passwords, credit card numbers, etc.
But in some situations, sessvars is safer than cookies - the contents of the cookies are sent to the server in the request, and window.name is not, so it’s more difficult to intercept them.