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
Related
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?
How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.
How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.
One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/
Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.
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 realize this might not be a best fit for SO, so please tell me where I should move/post this if that is the case.
My idea is after a user signs into the system, store the user preferences on the client in the form of cookies. If a user modifies said preferences, update the cookies. I need to do this because some of the preferences are client related and will need to be looked at via JavaScript.
I realize I'll need the preferences stored on the server as well. Just wanting to know if pulling them down into cookies is a good idea. My app is primarily ajax driven so I'd like to pull the preferences down once and just store them. I don't want to push them with each server request.
I'd like to avoid things like Local Storage so that I don't have to worry about browsers as much. Cookies seem to be supported heavily by all browsers.
Anyone concur or have a better way?
EDIT now that you've changed the question from when we first wrote answers:
If you are storing the preference data on the server, then there is no reason to keep preferences data on the local user's computer between visits As such there is no reason to put the data in a cookie as it just increases the size of every client/server roundtrip and takes storage on the client computer necessarily.
Instead, I would suggest that you simply put a preferences object in the page's javascript like this:
var userPref = {theme: "fun", permitContact: false, lastDisplay: "threaded"};
Then, you can get access to the preference values via javascript from any page with code like this:
if (userPref.lastDisplay == "threaded") {
// do something
}
Old answer before the question was edited:
If you want the client preferences to work from different browsers that the client might use, then you should store the preferences on your server (highly recommended). You can make them available in the web page at any time, by just including a small amount of javascript in each page that sets the properties of a preferences object to the value of the user's preferences. And, then you can have a preferences page where the user can modify/update the preferences and store the newly changed prefs back on the server again.
Cookies are for temporal state that may get cleared at any time and will only ever work on that particular computer. Plus, if you use cookies and if userA logs out and userB logs in on the same computer, the preferences will be wrong for userB.
Generally cookies are a good idea, provided that you don't have to store a lot of data. Just few things to keep in mind when using cookies to store stuff:
user can edit the preferences by hand so make sure you don't have things like is_root=false without additional server side checks.
this can be annoying when user removes cookies and preferences are gone, I would go for a server side preferences storage mirrored to cookies so JavaScript can use them.
Other possibility would be to serve dynamic JavaScript, with inlined preferences, instead of static files - you could serve JavaScript the same as you serve dynamic HTML, but then you have to be careful with caching.
You'll need to store the preferences on the server either way, as you don't want to trouble your user with having to re-create their personal settings every time they sign on with a different computer.
Just store them serverside.
I would like to import data that the user had entered into his profile on a website that I do not control. I don't want the user to hand me his login credentials to grab the data from the server-side (connecting directly to aforementioned website). I would rather prefer the login data to stay on the client's machine: It makes my service more trustworthy and I don't have to process sensitive data.
I thought that this can probably done with javascript without greater hassle. However, given the security risks, it seems to be blocked by browsers. See How to get data with JavaScript from another server?
So I think my question is already answered and can be closed/deleted.
I'm not sure I understand what you're trying to do, but there is no secure way to verify login credentials in a browser client. If you want to check login credentials, you will have to involve a server.
Some data can be stored on the client side, but then a user is tied to a particular browser on a particular computer and can't use the service from anywhere else. In older browsers data is generally limited to what can be stored in a cookie and cookies are not guaranteed to survive for any particular long lasting time frame. In the latest browsers, data can be stored in HTML5 local storage which allows for a little more structured way of storing data, but even then you're still stuck in one particular browser on one particular computer.
Based on your comments, it sounds you're trying to "cache" a copy of the data from web-site A that you can access from client-side code on web-site B on multiple visits to your website. If that's the case, then it sounds like HTML5 local storage may work to serve as a cache storage mechanism. You will have to figure out how to get the data from web-site A into the cache as the cache will be subject to same-origin access (domain X can only access the data that was put into HTML5 local storage by domain X), but if you can get manage to get the data from web-site A into your web-site B client-side page (perhaps using JSONP), then you could cache it using HTML5 local storage. You will need to realize that even HTML5 local storage is not guaranteed forever (so you need to be able to fetch it again from web-site A if required).
You said this
I don't want the user to hand me his login credentials to grab the
data from the server-side (connecting directly to aforementioned
website).
If you do that, anyone would be able to access any User's data, since you don't restrict access to data.
You also said this
I would rather prefer the login data to stay on the client's machine:
It makes my service more trustworthy and I don't have to process
sensitive data.
I'm really not sure that's a good idea. You still need to lock down personal information. But anyway, if you really want to, you can use localstorage -- modern webbrowsers support this.
Check out this link for a primer on local storage.
Storing Objects in HTML5 localStorage
Note that the user can clear the browsers local storage, so you still need to have a form to enter credentials.
EDIT -- if you want to save a user's profile information on the client, you can do that with local storage. But you still need to save the data to the server, else if the user goes to a different machine or even browser, they won't have their data. Plus, your server side model probably needs to associate a user's content with their profile in some way. I don't think there is any way around it.