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.
Related
I am storing some basic information to use in order to display information per user. I am currently using cookies to store and retrieve them, however I would like to employ a more secure tactic. I read that using local storage would be more secure and better to use, however, they don't seem to have any expiration date (like cookies) and unless you use a session storage, they will be stored indefinitely, which I don't want. However I don't mind using local storage if the information is encrypted, however with current encryption libraries, I have no idea how to use them.
Storing:
username
login attempts
whether the user is locked out or not
Some things to note: what I am storing is not being used for authentication, only to display error messages. I am using tomcat 8 to handle authentication and running the server (along with lockouts). Even though its not being used for authentication, I don't want to store the username unsecured or without expiration (1-2 days max).
Also, I'm not using an sql database (or other type) but plan to implement later, so don't suggest or ask about it.
I'm looking for the most secure method possible with relative ease, we have other security measures implemented, but don't want to leave any security holes open.
There is no such thing as secure that is purely client-side with two-way encryption. If you are able to decrypt something on the client-side, so can others.
Also, there are no particular security differences between session storage, local storage, and cookies. They're all client-side and able to be read by JavaScript on the same domain.
If you really want things to be secure, you have to store in on the server side, and transfer it only over HTTPS. Anything else is merely security through obfuscation, at best, which isn't real security.
As far as expiration, there is no automatic expiration with either local storage or session storage (other than the session storage will be cleared when the session ends). You could implement some with JavaScript, but that would only involve throwing away values when they are too old, and wouldn't happen until they visited your page.
The best you could do that is almost pure client-side would be to store some kind of key on the server, and when you go to decrypt, it needs to request the key (over HTTPS) from your server and use that to decrypt. That way, they can't decrypt it without having some kind of proper authentication onto your server.
However, if you're doing that, you might as well just store the info on the server in the first place.
According to MDN it is suppose to be more secure than cookies for storing persistent data on the client.
However, checking the localStorage of facebook.com, twitter.com, and linkedin.com I can see that it is not being used.
Oddly, linkedin does have the key ( in localStorage ) 8df when logged in , but trying to access it throws an error.
My guess (hopes this qualifies has an answer)
Web Storage is compatible with most common browsers: http://caniuse.com/namevalue-storage .
For things that don't need to transit with session: what probably happens is that cookies is most commonly known and easy to use. There are lots of companies with average skilled ppl, who will run away when confronted with things out of their confort zone.
Edit after Python Fanboy's answer (+1 from me): read his answer.
localStorage has this drawback which cookies doesn't have: it's stored values aren't sent automatically with all HTTP requests so without more implementation Your server won't know what's stored in browser's localStorage.
localStorage is supported in IE since IE8.
According to MDN it is suppose to be more secure than cookies for storing persistent data on the client.
Taking a quick look at Facebook's cookie, for example, I see things like userid, authentication tokens, presence indicator for chat, and window size. (Not posting my cookie here for obvious reasons).
The feature that makes cookies "less secure" (cookies are sent with the HTTP request) is the feature they need in this case because it's part of their communication protocol. Authentication tokens are useless if they aren't sent to the server for, well, authentication.
Simply put, they aren't using localStorage in this case because they aren't trying to store things locally.
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.
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?