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.
Related
Every time someone hits an API route I want to store that information in database, connected with req. IP.
Afther I would like to find some association rules based on similar searches.
Should I store some information in cookies or to use local dartabase?
Example on some hotels site:
I want to store info that i got a lot of request for cheap hotels in some specific area.
Thnaks.
Definitely in a database. Cookies wouldn't make sense because
You cannot rely on cookies for persistent data. They can expire, be cleared, etc.
Cookies can hold a very limited amount of data (4093 bytes usually)
Cookies are stored locally on your client's browser, you want information across all of your clients.
Tracking user behavior data is very common web feature. You may want to use a web analytics service such as Google Analytics rather then implement your own.
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'm developing a single page booking application using angular which interacts with my REST API.
I have various routes defined in my application and I'm using local storage to store the state of each page as a user fills in their information. Once the user has filled in everything, I post this to my API, generate a hash and redirect them to a payment gateway before coming back to a results page. The reason for local storage is so we can persist a users filled in details, even if they close the page and re-open it.
I shouldn't store sensitive information such as user names and addresses in local storage though, because this leaves me vulnerable to cross site scripting.
Storing this information on the server would break the stateless principles of REST API's.
Are there any suggestions on how to best architect my application?
Edit: the content below is incorrect. Cookies and local storage are both domain restricted. Local storage's main weakness is that it can be accessed and modified by local users and programs indiscriminately, and that treating the contents of local storage as trusted input opens the door to nasty DOM XSS and stored XSS attacks.
One option would be to use cookies to store the user's information. You could have a cookie per field, set the cookie when the user fills in the field, and read the cookies to populate the fields when the user loads the page.
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
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.