I'm using SessionStorage to store private contextual information needed for my frontend application. I have noticed that sometimes when navigating away to a different website (different domain, part of the application flow) and coming back again, the session storage is not the way I left it. Sometimes there is nothing, sometimes a couple of properties still remain.
I have seen this happen on Chrome incognito on Windows, and Safari private browsing mode. For Safari, I can detect private browsing and fall back on session cookies, however these will be pointlessly passed over the network so I don't want to make this my main solution. Also I can only detect it for Safari and not for Chrome.
I cannot find any articles stating this is expected behaviour. The fact that it does not always occur makes it even more fun to debug.
Is there a way to reliably use SesionStorage? Or are there any suggested alternatives for storing this sensitive information in a secure way?
No a SessionStorage is bound to the lifetime of a browsing context. This context is different between browsers.
From the spec:
The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent can support resuming sessions after a restart.
If you want a more persistent solution you can use LocalStorage.
Use LocalStorage instead of using Session Storage
But do not forget to clear the local storage when you do not need to store data further
for more information check out
Related
I need to maintain some data in browser like local-storage, session-storage, Cookies, Indexed-db. But the stored data would not be cleared(erased or deleted) even clear the cache and history of the browser. Is there is way to stored it ? Please share your Knowledge.
No, there is not a way. If there was, it would run contrary to the browser's privacy guarantees to the user - the user is explicitly asking for that data to be removed - and it would be a bug that browser vendors would quickly fix.
You need to come up with another storage approach outside of the browser. One is to store the data server-side, tied to credentials. The other is to allow the data to be downloaded/saved by the user to the filesystem, and then allow re-uploading back to the site.
I basically have two questions reguarding local staorage.
If i use localstorage.clear() in my producation application will it wipe out the entire localstorage from the browser. If the local storage had some content from other application.
If i user local storage for my application will the user be able to see or clear it even if the user is not currently using my application.
localStorage.clear() removes everything stored in it, and same goes for sessionStorage, but it's per domain/page, not per browser. This means if 3rd parts script in the same page/domain store stuff in it, you are removing their stuff too.
users can always clear their whole browser cache and affect your local storage data, unless your application runs with its own WebView (phonegap, cordova, native apps). If this is a regular Web App, users can always read content, or even modify it, through devtools.
The TL;DR is that localStorage is not a good storage solution, it's not secure, and it's ultimately not reliable.
Strawberry on top, it's synchronous, hence blocking, and limited in size.
I suggest IndexedDB instead, and yet malicious code could interfere with its data too, and users can read it, so I'd never store passwords in there.
I've seen there are ways to store data on the client, e.g. using localStorage, sessionStorage, or indexedDB.
AFAIK the main disadvantage of these technologies is that the browser may decide to clear out the stored data say if the device is low on memory (not sure if this is true also about localStorage).
I seem to fail to find information on some alternative storage which is more persistent: e.g. won't get deleted by a browser based on some decision.
Is there such a technology available? I am looking to use it next to ServiceWorkers for an offline first app.
I found something like this, is this something included with ServiceWorkers? (The article doesn't show much API). How is the support from browsers?
clarification: I am fine if the data can be deleted by user, I don't want it to be deleted by browser automatically based on some decision.
Since your app runs on clients' devices, and you don't have any real control on it, and your desire is impossible (' browser may decide to clear out the stored data' - not true. browsers might not be able to store data, or to get a reference to storages in some browsers and scenarios - e.g safari iframe and localstorage are not friends...)
Service worker do support indexedDB, so why not using it?
I recently developed a script to highlight text in a web page based on document.execCommand() but the changes are gone if I refresh my web page.
How can I keep the change for every user ?
As I am rather unsure what you actually want to persist I will give some generic information.
Some good reading at DiveIntoHtml5 on storage.
I would suggest taking a look at either sessionStorage or localStorage now while these are regarded generally as HTML5 the browser support is much greater.
You can see the support of keyValueStorage at CanIUse
You can store a key / value pair as follows:
localStorage.setItem("key", "value");
You can then retrieve the value as follows:
localStorage.getItem("key");
Remove:
localStorage.removeItem("key");
sessionStorage works the same as above but will only persist while the browser is open. It persists for the "session" of the browser. However localStorage will persist until it is removed by code or by clearing the browser.
There are two ways to save state.
One is to write client-side code that passes information back to the server for storage.
The other is to save what is called a cookie on the client computer. Normally JavaScript is not allowed to read or write files on the client-computer (an important security feature), but it can generate data strings that the Web browser can store in a special file commonly referred to as a cookie jar. The cookie jar is a configuration file, a file that provides information on how to set up the browser.
Remember that no cookie can be larger than 4KB.
Microsoft has a good guide on state management for web applications. Check it out and you'll see all the options that would come in question for you. Then pick whatever seems best fit.
Once you know what you want, you can search stack overflow for a concrete implementation of your problem. There's bound to already be an answer.
Edit: Table 5.5: "State Management Mechanisms for Web Applications" is the one you want to look at for an overview.
I recently discovered that it's possible for the user to clear HTML5's localStorage value, which caused me to wonder... exactly how persistant is localStorage? If Flash crashes and wipes all my cookies, would I lose my localStorage data? What if my local cache was cleared to make way for a browser update?
I've seen this answer, but it doesn't address browser crashes, updates, cache clearing, etc. Is localStorage really and truly permanent, as the aforementioned answer seems to mantain?
LocalStorage is not permanent. The storage belongs to the user so the user can clear it if they want to. Other web apps cannot mess with it, but the user is free to clear it or modify it if they want - it's their data, much like files that belong to a locally installed application are under the control of the computer user.
In addition, LocalStorage can be recycled when space is low.
You should think of LocalStorage as a long term cache that usually will remain with that particular browser on that particular computer, but will not always be there. Any truly persistent state must be stored on your own server.
Heck, if the user just decides to switch to another browser (much less a new computer), all Local Storage will appear to be empty in the new browser.
It most certainly isn't permanent. You shouldn't count on it.
Apart from situation where user is actively clearing the storage, his machine can be reinstalled. Or he can log from another computer. Your app better be able to handle that.