How can Javascript (running from a website on a remote server) access data from a user's local computer?
I have access to all the user's computers and they are all using Chrome.
The data may be stored in a file, a database, I can even run a webserver on their computers if needed, etc.
Is there any way for my users to for example allow my website to access data from JavaScript?
(maybe be there is a Chrome setting but I still want their browser to be secure)
As far as I know, you cannot access the files on the user's machine using javascript. This would be a huge security hole. You have to write a client (not web) application (windows app or whatever technology you are using).
this is not possible just using a browser, because as you said yourself it would`t be secure. You can use some kind of plugin which your users have to allow which then can access the local data on the computer.
It sounds like you are flexible as to where the data is stored in the user's computer. In that case use localStorage or Web SQL Databases. Web SQL Databases are no longer part of the HTML5 spec, but they are supported by Chrome. Using either of these methods will store the data on the users computer - right in the browser in fact.
Edit: In the application that provides the caller id data, have it launch your website with chrome passing in a querystring argument containing the needed caller id data. Then in your page, have it listen to the onstorage event, and update the dropdown when the appropriate localStorage data has changed.
In your caller id app, call:
%ChromeInstallPath%\chrome.exe "http://foo.com/caller?Bill+Gates#425-882-8080"
In your caller handler, use this JavaScript:
window.onload = function() {
localStorage.callerId = location.search;
};
In your page with the drop down list, use this JavaScript:
window.onstorage = function() {
setDropDownFromCallerId(localStorage.callerId);
};
What do you mean by access? does the server-side code need to grab additional info during processing a request?
Is this data that is exclusive to your app (that is, only you create, read, update it.)
If this data is exclusive to your app, then why not store it in HTML 5 Local Storage
Related
I am building software that runs locally on web browser. At first I was using C, but it was really hectic with HTML. So I decided to use JavaScript. This requires saving data and saving texts in plain text format. Can I do this with JavaScript? If not, how to integrate it with C or python so that I can save data?
Linux related answers will be helpful.
It depends on how/where you would like to save the data.
localStorage - A simple key/value store that lives right inside the browser. The data is specific to the computer, browser, and website, but the data persists from session to session with that particular site.
sessionStorage - Similar to localStorage, but the data is removed at the close of the session (when the user leaves your website).
cookies - if you want to instead store the data on the server, the data can be uniquely identified by a cookie stored in the user's browser. The cookie is sent automatically to the server on each request, that the server interpret and send back the desired data.
REST - You could also save your data on the server and implement a RESTful API, and use JavaScript to request the data from the server.
You cannot write to disk directly from JavaScript for obvious security reasons.
I know there has been a lot of discussion on the evils vs. the good of local storage. There have also been Chrome hacks for disabling a user's/visitor's ability to run JavaScript from the console which have had limited success.
None of these have addressed my question: can you prevent a user from editing local storage values in their browser?
This will never be the ideal or permanent solution to a current issue, I just need a way to do this until we can refactor the codebase to use IndexedDB.
EDIT: There is no sensitive data being handled in local storage for this app which is only available to local users on an in-house network. There are some data points that a handful of users have learned can be edited and it is these users the project owner is concerned about.
No, you can't. Even if there is a temporary 'solution' or hack that seems to work, it is still the web, so there is no way to prevent access to it. Trying to prevent a user from accessing a resource on their own system is doomed to fail.
Methods I can think of inside and outside the browser to read from and write to the local storage:
Inject JavaScript in the page to read the local storage;
Create your own browser or browser plug-in;
Read the SQLite databases in %LocalAppData%\Google\Chrome\User Data\Default\Local Storage.
You cannot do this. There is no way to control a user's browser in this way, and there should never be. That is antithetical to the nature of the Internet. Your server publishes code. People consume that code using some kind of browser. That's it. You have no control over what reads your code or what it does with the code once you've served it up.
Your approach to security is completely wrong. You cannot secure this on the client's side.
It's up to you to use localStorage securely from the get-go. That means you cannot trust any data stored there, and you cannot store anything there that you don't want the user to read. There, or in cookies, or in IndexedDB, or in any client-side data store. Security comes from inherently mistrusting any user-submitted data. You need to validate any and all data that a user sends to your server, full stop. Trying to prevent them from changing the data cannot work, because they can just write their own data. They can produce a request that will send literally anything to your server.
If you're storing sensitive data in localStorage or any other client-side data storage, you're doing it completely wrong, and you need to abandon that approach, because it cannot be salvaged.
I have a html5 app online that I am converting to a windows 8 store application.
It has a saving feature where an encrypted string is put into localStorage and deycrpted server side so that the user will have difficulty in cheating to get achievements.
However, I can't use the server in a windows store app because of the AJAX restrictions. So if I saved the savegame as plain text, would the localStorage variable be accessible by the user?
As #SLacks mentioned, anything stored on the file system is available to the user. You can, however, encrypt the data before it goes to the file system. If you write yourself a local storage controller to handler reading and writing, then you can access the filesystem through this boundary such that the rest of your code will not know that the files are encrypted.
I am a .Net developer, I know that the HTM5 localstorage is client-side storage technique. I want to get the local storage data on the server-side.
For getting cookie value from server-side we have Request.Cookie in ASP.NET. Is there any solution like that to take the local storage value directly on the server-side? Please guide me. I am using the .net 4.0 framework
Thanks,
Jibu
You will need to pass this information from the client to the server using standard HTTP techniques. Using javascript you could fill:
Hidden fields
Query string parameters
POST
Ajax call to the server
...
It will all depend on how your application is organized, what kind of information is being stored, its volume, whether you want to redirect or not, ... But in all cases this should be done using javascript since that's the only way to access data stored in localStorage.
No. The whole point of local storage is that it is local. One of the advantages of it over cookies is that you can store lots of data in it. One of the advantages of cookies is that they are tiny so the overhead of including them in every HTTP request to a given host is small. There two advantages are incompatible so you won't want them in a single technology.
If you want to get the data on the server, then you need to get the client to send it explicitly (e.g. via Ajax).
This is a widescope question. (like the length of a piece of string), but Ill try to make this helpful:
If you have values in local store in webserver I assume your webserver is JSON? Or did you use the sql local storage option?
Regardless of type of storage, you need to build an interface that both handles:
a) Reading data from your local database -> its important to involve some kind of date or index value in here if you are aiming to sync databases... this is to make sure you send IN ORDER all transactions / updates which are in your database. For this to happen you must store your data not only as tables with inforamtion but also tables that contain events of when updates happened and what was updated. (change tables). This will help check in the server end that everything is sync and also means you dont send data to the server that is not needed and can be kept locally. ((otherwise what is the point of local store if you cant save yourself server database space by only syncing waht is necessary?)
b) A HTTP local server to send the data to your destination client server or database server, etc (however you have set your infrastructure) - I recommend using industry standards for your language and server, which is Ajax and JQuery. If you do a lot of streaming of data then i recommend looking into RXjs with Ajax to get a http interface built (interface in this sense just means a way to expose your client like an API and post http calls)
c) An event loop to handle how often and what triggers the synchronization so that you dont destroy your users machine with overdoing it (you dont want to do this too often, but also want to it to be meaninful rather than "every night" maybe user enabled whenever you detect an event which triggers wifi available again.) - i recommend using native wifi reading capabilities built into Apache Cordova and also industry standards for your server setup (for example Express.js for Node.JS).
Obviously the backend server needs to have its API set up and authentication / authorizations, etc.
Cookies are great because a value written in website.com can be used in www.website.com (www is considered a sudomain of no-www). The downside is all the cookie values are sent along with every HTTP request to the server. So I'm looking for a local storage mechanism available natively to Javascript that works cross-subdomain and isn't transmitted to the server. Does such a mechanism exist? LocalStorage doesn't work cross-subdomain and Flash Cookies wouldn't work on iPhone.
Perhaps just redirect website.com to www.website.com or vice versa?
This seems like it would be the simplest fix.
http://www.scriptalicious.com/blog/2009/04/redirecting-www-to-non-www-using-htaccess/
If your users have an actual account that they login to on your server, then you could store the info server-side and just include a little javascript in the each page that will need that data with the appropriate data. When you render the page server-side, you can define a user object in javascript with appropriate attributes set to the data values that can then be referenced client-side. That way, you only include the data that is needed in a given page, the same user data is available no matter what computer the user logs in from (no reliance on persistent cookies). If larger pieces of data are needed only occasionally and you don't want to include them in the page in case they are needed, then make those pieces of data queryable via ajax/json so they can be retrieved only when needed.
If you're still intent on only storing it locally, then cookies or HTML5 local storage are your only options and cookies will be your only cross browser option that covers all browsers in use. At the addition of implementation complexity, you could combine a number of the suggestions:
Always redirect to www.domain.com so all user activity is on the same domain.
Use HTML5 local storage when available (the redirect in step 1 prevents sub-domain lockout).
Fall back to cookie storage when HTML5 local storage is not available.
One could presumably write or find an abstraction for HTML5 local storage and cookies so 99% of your code could be independent of which storage mechanism was actually being used. It looks like there are some jQuery plugins that do exactly that.