I am building a reactjs appliacation with a service oriented architecture in which data will accessed through web services. There is also a login feature in it. I am confused about where I store the user session after login i.e. localStorage or cookies. Which one is the best.
There are some pros and crons of both of that. Like,
local storage can be accessed using javascript and also all browser
does not support local storage whereas
cookies have too low web storage to store data as compare to local
storage and also with each server calls cookies will send the data
stored to server, this will affect the site’s performance.
So I just need your help to find the better way to do this.
Sorry for the english if something wrong. Thanks in advance for help.
Related
Is there any way to store persistent data for Chrome Extensions without using a web server?
Is Chrome storage persistent? https://developer.chrome.com/apps/storage
I want to avoid the costs of a server, but I also don't think localStorage is good enough because the user can delete it.
In fact, the only persistent data I need to store is the accounts that have logged into the extension on the device itself, so that info might be stored by Google's servers already?
I don`t think there is an non-server way to store extension data without user being able to modify it.
However there are lot of great services that offer free plans for many platforms eg. Heroku
I have a requirement where I have a postgresql database in a web site.
I want to run my web site in offline mode but the problem is that I have many ajax calls in my website which will not work in offline mode.
So I am considering using sqlLite but I don't know how to configure it, how to write JavaScript code, or even know if the users need to install sqlite in their browser or PC. Can anyone help to overcome this requirement?
I have used some local storage like Indexed DB it will work but that is called sqlLite or not I don't know.
please help
You do not need to work with Sqlite for addressing this, only take a look at following link for how to make web pages available for offline viewing.
If you namely want to use some database it is possible to use SQLite.
Look at https://github.com/kripken/sql.js/
Be care of using SQLite requests in main UI thread. Do not forget to implement workers for SQLite.
I'm pretty sure that you do not need SQLite.
Try using HTML5 LocalStorage API.
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
The Storage interface of the Web Storage API provides access to the session storage or local storage for a particular domain, allowing you to for example add, modify or delete stored data items.
If you want to manipulate the session storage for a domain, you call Window.sessionStorage method; If you want to manipulate the local storage for a domain, you call Window.localStorage.
https://developer.mozilla.org/en-US/docs/Web/API/Storage
I am new to angularjs. I want to pass localstorage variable from one angularjs project to another angularjs project. Both projects are on same server.
I am passing localstorage variable from http://site1.in/ as,
window.localStorage.setItem('is_provider', 1);
and I want to use this localstorage variable to http://site2.in/.
I don't know how to get this variable in site2.
Please help.
You can't, localStorage is per domain specific.
Local Storage Privacy
Website A and Website B would have their own local storage. Usually you would have to store certain information in a server database and sync it to the local storage.
I would use the local storage as a cache to get data once and update it at a certain interval depending on when I would want to invalidate the cache. For instance, you could sync with the server when the user A would log out and user B would want to login.
Have a look at the Privacy section in the HTML5 spec for Web Storage.
More information information and resources here: HTML5 Rocks.
Testing
I would suggest the use of a local server setup such as Linux/Mac/Windows, Apache, MySQL, PHP stack (LAMP/MAMP/WAMP) to test on localhost (127.0.0.1).
Most browsers will limit you to 5 MB per domain for every window and tab because of the HTML5 spec recommendation.
I haven't tried this, but you could perhaps have a look at changing the port number of the localhost in Apache's httpd.conf (to do so, find Listen and change the port associated to it) and see if this will do the trick. Basically, you run each test under a different port number to have the whole storage limit for each test.
An alternative would be to create a Chrome extension. You can read more information about this here:
Managing HTML5 Offline Storage
Manifest files
Maybe this link can help: http://www.nczonline.net/blog/2010/09/07/learning-from-xauth-cross-domain-localstorage/
And NO they cannot be without trickery
I found a way to pass data from one domain to another. You can use cross domain local storage to send data. I have used this and it's very simple. Refer to the site https://github.com/ofirdagan/cross-domain-local-storage
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 just started programming and now I'm making a simple HTML RPG game. It's pretty much working except I need a way to save. Is there some way to store all the variables in a text file that can be loaded later on? Thanks in advance!
You can use local storage or even cookies. local storage is your best bet, although it doesn't work in older browsers. cookies are (more) limited in their capacity (4KB vs 5MB for local storage) and also are sent to the server with each request, which may not be what you want.
Alternatively, you can store the state on your server (you'll need some server side scripting as well), and only store a user/gamer id in a cookie.
There is no logic to save it to .txt file. You can use local storage or even cookies. But local storage is better.