I'm developing a social app using Vue.js and Vuex store to keep app's relevant variables around.
Now I'm wondering if there are any best practices as to which parameters are better to be kept in browsers's localStorage?
Currently I keep token in localStorage, but wondering whether I should also keep username and other pertinent user data in localStorage, in order to preserve them from being perished on page refresh?
There's no correct answer here; just some thoughts:
Unless you have a good reason to, I wouldn't store the username in local storage. What advantage would you have by dong so? If the user logged in to their account from a different browser and changed their username, that would invalidate the username stored in local storage on other browsers. Most users expect that reloading the page should completely refresh all the data. People will think your site is broken if they reload the page and the username didn't update. The less stuff you store in local storage, the less you need to worry about the data becoming stale.
At a minimum, you should definitely store authentication token in local storage. From that, you can make requests to the server on page load to obtain all other data including the user itself.
I do not think that you need to store anything in local storage at all. If you have some authentication setup, you could store just your token in a session cookie and retrieve all needed data from the server.
Trying to keep the saved data on the client to a minimum is a good idea. Just keep the token in cookie, retrieve username (and so on) from the server when first loading the page. The retrieved data can be stored in some javascript vars. These values get only cleared on a page reload and then you have to retrieve them once from the server.
Reloads should not occur often or not at all, when you have a single page app.
Related
My idea is to reduce the number of requests to the server from the web client. Say, a view/component that shows user data (first retrieved before this view/component is rendered), if the user reloads the page (F5) then the whole application is reloaded and initialized again, so another request to the server to get that data again, is there any way to maintain or "caching" that state locally?.
I don't know how to implement this.
you can try redux presist link : https://github.com/rt2zz/redux-persist
or you can use localstorage : https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Like others have said, local storage is probably your best bet, but I don't think it's a very good idea. If the users reloads the page, that's essentially a blank slate for your app. You could get the data from local storage but how do you know it's still up to date? You'd need to check with the server anyway.
You should definitely look into a redux/store solution where you can store data for use while the user is using your app, so you can share data between components and don't have to fetch the same data every time. But actually storing it locally just reeks of bad practice, IMO.
So I'm working on a react application as a front and as the back python, Django and rest.
I'll do the front part in a few days, but a question spawn: how can I manage all my apps for the user with an account and the other (without the account)?
I look a few options but I don't really know which one is better:
local storage
context API
cookies
For example if the user is connected and wants to see him own profile page, he could without fetch in the code cause it's just a few information like name, email, ...
I don't know if it's enough to clear but hopefully enough to get some suggestions.
Cookies are mainly for reading server-side, whereas local storage can only be read by the client-side.
An other point is saving data, a big technical difference is the size of data you can store, localStorage give you more space.
Context API you'll use it eather you work with cookies or localStorage
You can call the API for fetching information the first time the user logs in, and then you could store the information on the app state for the whole session. If you want to store information between sessions localstorage works just fine, is easy to access. However, you'll have to check if this information exists when the user logs in.
Context API can help you to access the stored data easily by using useContext react hook API in other child components and manage them by React, but localStorage is a way to persists Context API changes with localStorage to get them back after every page reloads(prevent losing data in page refresh). But cookies have a maximum length(I don't know how much is it) which isn't the best way because it has security issues and a use-case of cookies is using them on the server-side by the backend.
When is it appropriate to use the many different ways that modern day AJAX based applications are storing data? I'm hoping for some specific guidelines that I can give developers. Here's what I'm seeing so far, and it's getting messy.
PHP Server Side Session: PHP Session data is probably the oldest way to store session based information. I'm often passing in parameters through various AJAX calls from JavaScript/jQuery objects - to store in PHP Session. I'm also returning objects of data (some session information) back through as a response/result to JavaScript/jQuery methods.
Browser based Local Storage: This is often used to store data that needs to persist on the front end, yet I'm uncertain at times when to use it. One good use was to store geolocation information from navigator.geolocation. I've been storing a lot of information here, but I am not certain that is wise. It never seems to expire, but can be deleted from Resources.
JavaScript Object with config parameter(s): I've been building JavaScipts objects with an init method that sets-up a 'settings' parameter. This is very useful as I usually build it from data passed in from PHP. With jQuery Mobile this data can even persist from page to page and change with AJAX request responses.
So, what guidelines would you give on usage of each?
PHP Session data is NOT Permanent Data storage as when you destroy the browsers session you will loose the Data. This is useful if you dont
want to permanently store data.
Browsers Local Storage is Permanent unless you delete the data yourself or you clear the browsers cache. Some users clear the cache from time to time so this can be a problem.
Any other method Such as Objects is not permanent Data storage.
Other Browser related Permanent storage are COOKIES (if you don't
expire them at session close), IndexedDb (Check here for current browser support http://caniuse.com/#feat=indexeddb).
So depending on your Website or App you need to decide what data needs to be
stored for a short time, or for long time or forever until you deleted it manually.
As an example, you will use LocalStorage if you were storing
Bookmarks, and if you were Storing Geolocation points you use Cookies
and expire them after you close the browser or the App.
If you were Logging in to an Account using PHP then best practice is to create a PHP
Session, and even change the session timeout when the user clicks
(Remember me).
These are just a couple of examples from thousands of possible needs.
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.
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!