what is $cookies vs localSTorage.
$cookies.myFavorite = 'Steve jobs';
localStorage.myFavorite = 'Steve jobs';
$cookies is an Angular module that takes browser cookie functions and wraps them in Angular. Cookies have a smaller storage capacity than localStorage (4k as opposed to 5m) and have the ability to be configured to prompt the visitor for use/acceptance each time you try to use one. This can rapidly detiorate the user experience. Cookies are not recommended for long-term storage of information in a browser for exactly these reasons. Cookies also have a reputation among the technologically illiterate for spreading viruses or somehow otherwise being harmful, neither of which are deserved or completely true.
localStorage (and its companion sessionStorage) are somewhat new to the web with the coming of HTML5 and are very useful. While they can be specifically disabled via settings, most browsers come pre-configured with them turned on and you don't need to worry about it. Unlike cookies, there is no way for the user to be prompted each time the browser wants to use these functions. They are either off or on, and there is no in-between. This makes for a much more seamless experience in your web applications.
localStorage is recommended for storing things in the browser that will persist beyond the current session. To remove things in localStorage you have to explicitly clear them via localStorage.removeItem(itemName).
sessionStorage is recommended for storing things that you do not want to persist beyond the current session. This is because sessionStorage is wiped completely clean when the visitor leaves the domain or closes the browser. This makes it an excellent repository for session-based information such as temporary shopping carts, lists of items to compare, etc.
The caveat here is that both cookies and browser storage can be cleared by the individual user and should not be completely relied upon for storage. Your best bet is always database storage that resides on the server.
$cookies will be overridden and they have a temporary storage.
localStorage have a persistent storage.
Related
After doing a bit of research on this topic, it seems like session keys have typically been stored as cookies which is nice because they get automatically added to requests. I've been seeing that developers prefer localstorage to cookies due to less restrictions, though. I am building a React frontend, so persisting a reducer in localstorage and managing the session key in that reducer would be very easy. I would need to append this to requests, which seems to be the only downside. Wondering if there is a standard for how this should be done. Thank you in advance!
There are only a few places you can store your keys in the browser:
SessionStorage / LocalStorage
Cookies
Web workers
in memory
Cookies
Cookies are one of the best places to put sensitive keys as long as it has the correct configurations/attributes with them. This includes, httpOnly, secure, SameSite, Domain and making sure they expire in a reasonable time. more reading here for how to set these attributes properly.
Cookies are good to use since they are as secure as HTTPS and cannot be accessed via javascript (if correct atrtibutes are set i.e httpOnly). But note there are still vulnerabilities you have to watch out for such as a CSRF attack, and you would have to include a CSRF token to counter this vulnerability since the cookie gets added to the headers automatically by the browser.
LocalStorage / SessionStorage
LocalStorage and session storage are poor places to keep keys since they are accessible via javascript. You can look here on how Auth0 recommends to store keys, and note they persuade not to store it in localStorage for said reasons.
In Memory
You can store the key in javascript memory (use a closure to encapsulate your key). This has a downside as the key will not persist after refresh/close/new tab etc but is still pretty secure
Web Workers
Web Workers are another place you can store the key. Workers run in a separate global scope than the rest of the application so it keeps them pretty secure, and you can have fine grain control as to what apis to send they key to.
Auth can be tricky and it can be easy to forget to include something important, so make sure you are well read on all attributes and how each piece works. Or go with a pre made options like Auth0 or single sing-on.
I would have liked to know what the difference is between LocalStorage and SessionStorage. Also, in the context of authentication, what should be used? Because the user can view and change the content of SessionStorage and LocalStorage in the browser.
Session Storage is deleted as soon as the browser tab in question is closed. Local Storage exists until deleted or it hits its expiration (usually a very long time). Neither should be used for Authentication unless you don't have any private data being thrown around. If it's more of a pet product to keep track of someone being logged in, Local would be the better of the two.
https://www.quora.com/What-is-the-difference-between-sessionstorage-localstorage-and-Cookies
Cookies, session and local storage serve different purposes. Cookies are primarily for reading server-side, local/session storage can only be read by the client-side. In your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
LocalStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data - unlike cookie expiry.
I use the gpl version 5.1.1 of ExtJS, no other library or framework (no ASP...).
I use LocalStorage proxy in a Store to store/save the user preferences. I call "user preferences" the default filter values and other display options. I use LocalStorage because users mostly use the same PC and their preferences can be stored localy.
I don't plan to save these data to the server DB, but I could.
I would like to use Memory proxy for session variables which must be reinitialised every time the user log in.
This proxy simply uses a local variable for data storage/retrieval, so its contents are lost on every page refresh.
This would work fine for me.
I do not use SessionStorage proxy... But I could use this proxy for session variables.
Note that session storage is different to local storage (see Ext.data.proxy.LocalStorage) - if a browser session is ended (e.g. by closing the browser) then all data in a SessionStorageProxy are lost.
This would also be a solution. The browser versions are not a problem, they are compatible with SessionStorage.
I would like to know if I use the correct principle to store user preferences or if I should use another way.
What is the "best" solution between memory proxy and SessionStorage?
The memory proxy will only keep the settings for that page load. If you leave the page then everything will be lost. This does not require a specific browser, any browsers will work even IE6. Even is the user is logged into your app, when they leave the page the settings will be lost and will have to be retrieved on next visit.
The session storage proxy (using HTML5's SessionStorage api) will keep the settings in browser memory for the browser's session. You can leave the page and come back to it and the settings will still be there. The settings will be lost when the browser is closed. This requires a HTML5 compliant browser (IE10+). If the user is logged into your app, when they leave the page but come back to it the settings will still be local (unless the browser is closed).
The local storage proxy (using HTML5's LocalStorage api) will keep the settings forever or until cleared programmatically or by the user manually. Leave the page, close the browser and the setting will still be there when the app is visited again (unless otherwise cleared by code or user).
I have an angularjs app that is on a separate domain than my backend, and the users from my backend all have roles and permissions that allow them access to various areas and elements of my frontend.
Before, I was just storing to a cookie and checking as I needed through the use of angular services and whatnot, cool.
Now the permissions datum have reached the point where they are too big to store in a cookie in the browser. And I'm avoiding Localstorage for fear of user tampering.
The Question:
How do I store the users sensitive data (or anything sensitive, really) that are too big for cookies on the client side in a manner that is safe and doesn't require API calls all the time to get?
I don't want to have to phone home every page change to get this data direct from the server when I need it, because I feel this would be really detrimental to the speed and flow of the site, not to mention the frequency at which this would need to happen would be ridiculous for my app.
Keep in mind that I do proper permission checking on the backend before carrying out any actions, but I'm more concerned about users tampering with their permissions to show certain elements that were removed on the frontside before.
What would be your solution or your advice on this?
If it ends up on the user's computer, regardless of whether it's in a cookie, in local storage, in the URL, in the browser's cache, or anywhere else on the user's computer, assume that the user can see it and mess with it. (You could encrypt it, but if your client-side logic knows how to decrypt it, you're back to step one.)
The best that you can do is exactly what you've described - be sure that the server only carries out authorized actions, and never trusts what the user tells it.
I am finding myself placing all my data from my api calls in the device local storage and I am not sure if it matters whether I put things in local storage vs putting them in a service. When should I use local storage from device vs using a Angularjs service?
You are a bit mingled up with concepts. When it comes to angularjs services, they persist data as long as the page is not refreshed, as soon as you refresh your page or close the browser tab, The data's gone.
Consider Angularjs services as mere variables that you declare, which are scoped to the lifetime of your browser tab. Hence, you can use it to store some temporary flags and values that aren't meant to be carried forward to next session.
Whereas, When it comes to localStorage, consider it as a database kind of stuff. Whatever you store in localStorage, is saved inside the browser, and will be available across multiple tabs, and sessions of your apps [Until and unless user clears browser data].
Since you're using Ionic and Cordova, you must use localStorage to save stuff such as user name and password, so that the user can use them the next time he opens your app. Take a note that, closing your app is equivalent to closing a browser tab.
Whereas, if you have certain data that keeps refreshing each time user visits your app, you can use services to store them, so that they are removed as soon as the app's closed.
Metaphorically, localStorage --> Secondary, non-volatile Storage, angularjs services --> Primary, volatile storage.
Data stored in local storage is persistent. So, if you reload you web app the data in local storage is till there. Local storage is typically limited to 5MB. See this
Services are in memory constructs. So, if you place anything in service it is in the browser's memory and are lost when refreshing the browser.
So it depends on what you need.
You can use this localstorage plugin for your app. https://github.com/grevory/angular-local-storage