Is there a way to clear all of my application's local data with javascript?
I would like to clear:
Session Storage
Cookies
Local Storage
Application Cache (html5 spec)
Think you would have to deal with each individually as each browser would implement differently.
sessionStorage.clear
localStorage.clear
and for cookies there is already a good answer on SO
You could of course just put these into your own function.
If the application cache is server side you could have an ajax call to a http post that deletes this.
UPDATE:
it is advised against clearing application cache, http://www.whatwg.org/specs/web-apps/current-work/#expiring-application-caches. What would you be storing there that you would want deleted?
Related
Till now, I was using cookies to save some preferences, for my websites. But with time, this has gone very big, and now it is exceeding the limit of 4096 chars.
So I have to find an alternate way of storing the data. Here I find, using local-storage can serve my purpose. But I couldn't find any example, how I can save some value in local storage of the browser from node js. Previously I used to send the cookie value with response, to save the cookie, can we do something similar for local storage.
I see some of the npm modules like node-localstorage etc. , but not sure, how I can save the data to the browser.
I would at first suggest using some kind of persistent data handler. Maybe a database on the server, or if you want to avoid server-handling, maybe you could use something like Firebase to handle your persistent data.
There is probably a ton of npm modules to save to local storage, but I guess it depends on what you're using it for, but maybe this module can help? Otherwise if you're using the cookie to send information between different requests, maybe you could use query-strings on your requests instead?
So instead of saving preferences to a cookie, you send a querystring with the preferences on each request using
encodeURIComponent & decodeURIComponent()
Lets rewind to the days of cookies, ok not that far as they are old but still relevant. You can set them and read them with PHP; despite the fact they are a client side technology, you can also use JavaScript, fully client side.
Coming forward in to the future, HTML5 Local Storage, also a Client Side technology can not be set by PHP, you are solely reliant on JavaScript.
It seams as though this is the reverse way of doing it (taking away not adding). Surely to have the ability to set this data with PHP is helpful and possible somehow considering Cookies can be.
So why isn't it possible? What was the reasoning in not designing a way to do this?
Update Correct me if I am wrong, but localStorage is a replacement of Cookies, so does this not mean you are losing functionality?
Lets rewind to the days of cookies...You can set them and read them with PHP; despite the fact they are a client side technology...
No, they aren't. Cookies are primarily a client/server technology. They were specifically designed to allow the server to send information to the client that the client will then send back to the server. From the spec:
This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol.
Although you can access them via client-side JavaScript, that isn't what they were created for, nor is it their sole purpose.
Web Storage (what you've called "HTML5 Local Storage") is client-side only. If you want to send that information to the server, you do it via ajax or by sending a form.
Why? That takes us into the land of speculation, but we already have cookies, whereas we didn't have a client-only way to store data prior to web storage. A client-only solution is very useful, not least because we can store a large amount of information without it being unnecessarily added to each and every HTTP request that client then makes to your server, which is a waste of bandwidth if the information is only needed client-side.
cookies … can set them and read them with PHP; despite the fact they are a client side technology
They aren't a client side technology. They are an HTTP technology. The are embedded in the communication protocol used between the client and the server.
Local Storage is a purely client side alternative to sessions and databases, which were already available on the server side.
It's purpose is for storing data that is too big for cookies. If you could edit it on the server, then the contents would have to be sent in every request, which would be very expensive. It would also turn Local Storage into "Cookies without the restriction on size".
Is the newly introduced localStorage facility in html5 a replacement for cookies? Does localStorage help in making the http from stateless to stateful. Or is the localStorage an addition to the cookies. Do you still need to use cookies to track the user or even that can be done ny localStorage?
Local Storage allows client-side javascript to save state on a local machine (if LocalStorage is supported). That is one thing that client-side javascript might use cookies for, but cookies are also used for other things that LocalStorage cannot replace.
For example, LocalStorage is never seen by a server so if a server wants to keep track of some client state itself or track something across multiple pages on a domain, then the server can't use LocalStorage for that and will likely still use cookies. Cookies for a domain are sent to the server with each request on that domain (thus enabling things like authenticated login across all pages in a site). This is something that LocalStorage cannot do.
LocalStorage has nothing to do with HTTP; it's a purely client-side feature.
On my previous websites, I used to use a cookie to display a pre-home page only on the first visit. That worked great (see for example here), but using cookies is not so trendy today, so I want to avoid it as much as possible.
Now, my new website projects almost always have pre-home launched via javascript (showing a modalbox), so I don't need to do any action on the server side. I'm considering to use HTML5 localStorage instead of cookies, with a fallback on cookies if the browser does not have localStorage. Is this a good idea? What is the impact in terms of usability, privacy protection and website performance?
Using localStorage will improve usability for users that have disabled cookies. But I know that some HTML5 features are only opt-in (like geolocalisation) in some browser. Is there any restriction like that for localStorage on any browser ? Is there any case where I will get a JS error if localStorage is available but deactivated for my site ?
Usability
The user will not know if you are using localStorage or a cookie. If a user disable cookies, localStorage will not work either.
Performance
There is no noticeable speed difference between the two methods.
sessionStorage
sessionStorage is only for that browser tab's session. If you close the tab, the session will be lost and the data will be lost too, it's similar to a session variable on any backend language.
localStorage
localStorage will be available for any tab or window in the browser, and will exist until it is deleted by the user or the program. Unlike a cookie, you cannot setup expiration. localStorage has a much larger storage limit as well.
Your Questions
You are not using this data server side, so you don't need a cookie. localStorage is never sent to the server unlike a cookie.
If the user disables the cookies, localStorage will not work either.
Fallback Example
You can use a Modernizr to verify if localStorage is available and if not, use store a cookie instead.
if (Modernizr.localstorage) {
// supports HTML5 Storage :D
} else {
// does not support HTML5 Storage :(
}
You can also forego Modernizr and use the check typeof Storage !== 'undefined'.
Comparing LS vs cookies is comparing apples to oranges.
Cookies and LS are completely different things for different purposes. LS is a tool that allows your client (javascript code) to store its data locally, without transmitting it to the server. Cookies is a tool for the client-server communication. The whole point of cookies is to be sent over with each request.
In the past cookies were often abused to emulate the local storage, just because it was the only possibility for a javascript application to write anything to the client's hard drive. But generally LS is not a replacement for cookies, so if you need something that both client and server should read and write, use cookies, not LS.
One point to add, unlike cookie normally shared cross protocol, the storages stick to same-origin policy. As a consequence sites share the same domain but hosted on different protocol do not share the stored data.
Say if your website need to work across http and https. For example, when user clicked the "purchase link" they will land on https secured checkout, then the checkout won't be able to retrieve the data previously stored on http site, even when they share the same domain.
It doesn't look easy for the server to read the localStorage. That may come in handy though, knowing your data is all client-side, making it safe from sniffing.
Cookies can't be written over, only added to and read:
alert(document.cookie);
document.cookie = "nope";
alert(document.cookie);
The one thing I didn't like about using 'localstorage' is that all your script code is visible when you 'inspect' (F12) the page. Go into SOURCES and from the left panel locate your website name and open it. All your code within the tags is totally visible. So if you've got some sensitive values on display, liked hashed passwords, special words, they all there for the world to see. I'm not sure what the world will do with this info, but it's not very secure.
if the following conditions are met:
all pages are static (eg, templates to be filled in via websocket data)
all pages are public
session id and status communicated through websocket
client session state stored via sessionStorage and/or localStorage
is there still a need for cookies?
The localStorage/sessionStore can indeed replace cookie Storage. Both are on the client.
The neat thing about cookies is that they are auto appended to any HTTP request. There is absolutely nothing to do from a coding standpoint. But since you want to use websockets, it doesn't apply - you will still need to do wiring with the sessionid stored in the localStorage.
So the answer to your question is "No" you don't need cookies in your scenario
If the pages are 100% static then there is no state, so the question becomes moot, since no mechanism at all is required for preserving state across requests.
However, if any part of the pages are dynamic then cookies may still be necessary for preserving state across multiple sessions. Since cookies are stored client side but passed to the server with every request they are a mechanism for synchronizing client and server state. Of course, you could implement this via an AJAX request and localStorage yourself if you wanted to.