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
Related
I know that local and session storage capacity is 5MB and cookie has 4MB,
If I want to store More than 5MB data in web storage ONLY then what is the alternate solution for this?
Looks like one of the options would be to IndexedDb. Which also has some limitation and they depends on users storage configuration
You can check supported browsers here
One solution that is provided by the browser is IndexedDB.
If the accessibility may be an issue, you might want to check the caniuse page to see what browsers are supported.
I think this is what is used by PouchDB in the background. But you can use it with other backends like localStorage or memory. So it may be good if you are not sure of the quantity of data first, but want to preserve the same API. Also PouchDB can sync with non browser database which is pretty cool for web applications that need to work offline.
I am working on a chrome extension which has to store data of its user. For that I am using a hosted server which is running a mysql database. But currently any addition or change in data fires a request to the hosted server.
Chrome extension provides chrome.storage.local API which is suitable to store data upto 5mb. I want to take advantage of this storage API to reduce number of requests to my hosted server by using it as a temporary storage.
I am planning to use chrome.storage.onChanged.addListener and chrome.storage.local.getBytesInUse to check if data stored crosses a certain threshold value and then only fire an ajax request to the remote server to save the data. Upon successful response, the old data in chrome.storage will be flushed off.
But there are chances of losing some new data which is created during the process of request/response cycle from the server.
How can I prevent any loss of data? Is there any alternative solution to this optimization problem of reducing number of requests to the remote server from the extension?
Thanks.
This isn't really a question about chrome extensions. It's more about persistent databases that work offline and synchronize intelligently. Which happens to be a very hard problem to do right.
The easiest solution is to use chrome.storage.sync. That buys you persistence for free with the caveat of limited storage. You should definitely see if this is feasible before trying other options.
Otherwise, I recommend looking into 3rd party options before rolling your own solution. You might have heard of progressive web apps, which work offline, and sync when internet is available.
An article about the advantages of progressive web apps
Google Tutorial
PouchDB, a well regarded web database that works offline and syncs to other databases
Look into those. It'll be well worth the trouble. otherwise you'll just end up building hacks on top of hacks trying to get syncing to work.
... one last thing... make sure to add your remote database's URL to your manifest's permissions.
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
Currently we are using localStorage as persistent storage in our application. But we noticed that it is prone to data loss. Here is some links which supports this:
HTML5 Local Storage Not Persistent
localStorage data persistence
http://www.sencha.com/forum/showthread.php?132952-localstorage-doesn-t-save-all-data
So now I'm searching for a new solution. It will be good if this solution is supported by chrome/safari at iOS/Android. Could someone suggest something?
if its a website then, there is no means of persistent storage on browser. localstorage, database, cookies, everything is erased if user don't require them. So the only option would be to store the data on the server.
OR
if it is a mobile app (phonegap), then you can use SQL Lite.
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.