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?
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 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 want to save a JSON object to a file at client to persist it for future usage, I have tried following line
window.open("data:text/json;charset=utf-8," + escape(JSON.stringify(obj)));
and it works!! Problem it asks user the location and name of the file for saving. What I want is I want the user completely unaware of the fact that something is being saved for future use or atleast keep it to minimum possible user clicks.
How can I give the file name and location statically in window.open() ?
Thanks in advance,
EDIT
Just to make it clear that " I don't store arbitrary or unwanted data. All the users are registered users of the system." In normal conditions I don't store anything locally. However I want to store some JSON objects if the network was not available at the time of form submission.
One obvious solution will be to use cookies. Since Cookies can be accidentally deleted due to user's browser settings. I need a way to persist the data till the network becomes available. It will be greater to have cross browser support.
If you want to persist data, then use a storage API, you can't play games with the user's filesystem.
You can't do that, it is a question of security on client side.
I want the values for cross-browser support, even if the user changes the browser he/she should be able to proceed from where he left. I am storing information in JSON objects.
I think users don't expect a web application to share information with other browsers on the same machine this way. Also, I doubt many users change their browser too frequently anyway to warrant a privacy-invasive feature like this. You should either consider storing the information on your server (by forcing a user to register or using common accounts like OpenID, Google, Facebook etc.) or on the client side by setting a cookie or using the mentioned storage technologies.
If you really want to restrict stored information to browsers on the same machine, and don't want to permit access by the same user on different machines, you could take a look into LSO ('Flash cookies') which seem to be saved browser independent. You don't need any user confirmation for storing LSOs.
Update: Flash isn't supported by browsers as it used to be and not widely used nowadays, so LSOs aren't a good option any more.
FileSystem APIs is part of HTML5 spec and it is possible to access file system in a sandbox for a certain website in modern browsers, here is a good tutorial:
http://www.html5rocks.com/en/tutorials/file/filesystem/
However I would go with LocalStorage API for that matter which has better browser support:
http://www.w3schools.com/html5/html5_webstorage.asp
FSO.js wraps the temporary/persistent FileSystem API and will allow you to easily read/write files... only supported by Chrome right now, but the spec is coming along fast. :)
As has already been mentioned in the comments, this is not possible without express user consent for obvious security reasons. however, as also mentioned in comments, you shoudl/could store the information in a cookie which will then be retrievable when the user returns.
something like this would do it
document.cookie="cookie_name="+required_value+"; expires=Monday, 04-Dec-2011 05:00:00 GMT";
obviously the expires time will be as long as you need the information to persist.
hope that helps
For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.
Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.
Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).
You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.
Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.
I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.