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.
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.
In web application , How secure is local storage in Html5 or else is there any other way to secure the sensitive data in local storage.
Project Structure:
Front End: Html5,Angular js, Middletier: Asp.net webApi , BackEnd :Sql Server.
Once user login into the page, that credentials is encrypted by using some cryptography algorithms.It will be stored in db.
After that every child action like products list, order details, book history ,add product need to validate that.
While refresh after the page, data gets lossed so need to persist the data so i have choose localstorage. stored the username and password encrypted using some js algorithms and in put in local storage.
I feel it as not safe , because of any one can steal the data from the browser tools.
Is there any alternative approach in this scenario or else this approach is secure.
can anyone help me to process.
There is something that every Webapp Craftsman must know:
There is no repository beyond your firewall that can be fully secure. Why? Because the open door that you NEED to allow your application manipulate the data is accessible to everyone.
Imagine that you decide to encrypt the content of the local storage.
This will prevent someone with access to the browser's local storage (e.g. the developer tool) to be able to read/write the data. But how your application will access the data? You have two options:
Send the encryption algorithm + passphrase within the client-side app. This will expose all your data if someone manage to read the code of your app and access to memory of the browser (e.g. the developer tool)
Send every data from the client-side to the server to be decrypted there. Well ... this is pointless. Is better to store the data in the server for that matter.
You can try as much as you want, you will need an open door, and that open door can be use by anyone.
But I've a question for you: Do you really need a fully secure repository in the client side? This kind of repository weren't created for be fully secure, but they are secure enough!
For example, the session cookie of your web app is stored by the browser right? And if someone steal that cookie, it can impersonate the user and your application will never notice it, right? This is pretty scary when you think about it.
Nowadays nobody put to much thinking on this because browsers are secure enough to protect cookies from malicious access. And of course, they did the same to protect the local local/session storage, IndexedDB, WebSQL, etc.
So, if your data is more precious than your user session, keep it in the server. If not, go ahead and put it in the browser.
PRO TIP: Consider encryption when storing in a no secure repository to make it harder to get. But remember that this comes at a price: you will not be able to use the query system of those repositories to search over encrypted data.
First off, Thanks in advance to anyone who resolves/helps to resolve this problem. And sorry if this is a duplicate(I couldn't find it anywhere, so posted a new question).
So the main issue is I want my webpage to display an alert message, subsequently from when a user visits the page for 2nd time onwards, so I thought IP logging using cookies would be the most unique thing to do, please do suggest if there's a better thing to use.
Browsing till now, did not get me a way to log IP in cookies. Also, the solutions I found were somewhat similar but they were in PHP, which, I'm not good at.
I would prefer using JavaScript as opposed to jQuery, but all and any help is appreciated.
First off before I give different ways of identify repeated visit and display a message after 1st visit.
I would recommend not using the IP address because there could be multiple machines behind the NAT routers sharing the one IP address, there will also be a the problem of mobiles always changing their IP address because they will also be connecting to different networks.
There is multiple ways of doing this:
I would recommend using either Option 3 or Option 4 so that there is nothing stored on the users machine. It is then much more secure that client side because people can store of JavaScript on their browsers.
Option 1:
You could have a client side local storage by using the HTML5 Web Storage.
HTML5 Web Storage
Before HTML5, application data had to be stored in cookies, included in every server request. Local storage is more secure, and large amounts of data can be stored locally, without affecting website performance.
Unlike cookies, the storage limit is far larger (at least 5MB) and
information is never transferred to the server.
Local storage is per origin (per domain and protocol). All pages, from
one origin, can store and access the same data.
Option 2:
You could go with using a client side cookie, which you would set and remove with JavaScript:
Cookies are data, stored in small text files, on your computer.
When a web server has sent a web page to a browser, the connection is
shut down, and the server forgets everything about the user.
Cookies were invented to solve the problem "how to remember
information about the user":
When a user visits a web page, his name can be stored in a cookie.
Next time the user visits the page, the cookie "remembers" his name.
Cookies are saved in name-value pairs like:
username=John
I've actually done an example of this few days ago.
COOKIE EXAMPLE
Option 3:
You could have a session, which is a good way of checking if you are having users logging into your website/application:
PHP Sessions
A session is a way to store information (in variables) to be used across multiple pages.
Unlike a cookie, the information is not stored on the users computer.
When you work with an application, you open it, do some changes, and
then you close it. This is much like a Session. The computer knows who
you are. It knows when you start the application and when you end. But
on the internet there is one problem: the web server does not know who
you are or what you do, because the HTTP address doesn't maintain
state.
Session variables solve this problem by storing user information to be
used across multiple pages (e.g. username, favorite color, etc). By
default, session variables last until the user closes the browser.
So; Session variables hold information about one single user, and are
available to all pages in one application.
Option 4:
You could use server side cookies (this way it's not stored on users machine), this is a good way of identifying a user (visitor):
PHP Cookies
A cookie is often used to identify a user.
A cookie is often used to identify a user. A cookie is a small file
that the server embeds on the user's computer. Each time the same
computer requests a page with a browser, it will send the cookie too.
With PHP, you can both create and retrieve cookie values.
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 just want to know can I create registration page with using javascript in html page and store all details to the client-side cookie session or I should have a database to store all information there?
Any help would be appreciated
This has to be server side, in a database. Why would you want to store this on users computers? What would happen if they moved to a different computer or deleted their temporary internet files? You'd cause problems.
Hi there, I just want to know can I create registration page with using javascript in html page and store all details to the client-side cookie session
You could, but then the user would be registering with their browser rather then with your website, which doesn't appear to make sense.
should have a database to store all information there?
Having a server side system which stores information in a database is the standard approach.
If you want to persist your user information and if you want your user be able to login to your application from anywhere, then you should use a server side database and store your registration information.
Yes, you could do that, but it would not provide any kind of security. It would also mean that you lose out on the ability to keep track of your users, unless the cookie is read by the server. Finally, your user's registration would only be valid on their computer, again unless there is a way for them to retrieve their information from the server (which means the server will need to have it).
If it's a HTML5 app you could use the localStorage and sessionStorage Objects to store your info however if the items you are collecting are security sensitive I'd send the info to a database or a protected file on the server. Leaving sensitive info in a cookie isn't wise.
If you're working with passwords, get that stuff into a database and encrypted/salted!