I am about to use Storage.setItem() in one of my Angular project but wanted to check how does browser handle the scenario when two separate web apps try to set the storage with the same key.
Does the previous value get overridden?
Or does the browser have a way to seperate out storage for each individual web-application
localStorage is set on a per domain basis. So keys won't clash if they are on different web applications in my opinion.
See In HTML5, is the localStorage object isolated per page/domain?
Related
I'm working on an application where I have multiple webworkers running together. These webworkers are developed by third parties, and are not trusted. They provide postmessage APIs to each other.
I would like to enable the webworkers to have safe access to local storage. IndexedDB is the standard choice, however I need to ensure that a malicious webworker cannot interfere with the data of another webworker.
My original idea was that I could 'domain' each webworker somehow. Each one gets access to its own piece of IndexedDB, and cannot see the storage put in other pieces by other webworkers. At the moment, I do not believe this is possible since I need the workers to exist together in one iframe.
My next idea was to have a single, trusted webworker that has IndexedDB access, and set up sandbox rules for all of the other webworkers such that they can't use IndexedDB at all, but instead must communicate with the API of the trusted webworker to store and retrieve local data. My current understanding is that I can get this to work if I use two iframes, where the first iframe has access to IndexedDB and runs the trusted webworker, and the second iframe is in a different domain where non-malicious webworkers know not to use the storage.
I am not a huge fan of the two iframe solution - it's complex, has performance overheads, and requires webworker devs to know they can't safely use localstorage even though they actually have access - and I'm looking for a better way to sandbox specific webworkers away from indexeddb.
I'm dealing with a dilemma regarding chrome storage.
My use case it that I have a Chrome extension that will store the user's cleaned tabs on a daily basis. One of the requirements is that a history is kept, so I store tabs in an array per day.
My current implementation is to store to chrome.storage.sync, however this storage is way to small for what I intend to use it. It is in fact, rather tiny.
The second option would be to use chrome.storage.local which has sufficient capacity, but we don't want the user's historical tab data to get lost, so this poses the problem that we actually need sync.
The third option is to use localstorage and implement a custom sync to some free remote service like Firebase.
My question is:
Is my understanding right that chrome.storage.sync is only to be used for some configuration data? And is there a straightforward way to force sync the 'local' chrome storage anyhow (might Firebase be an option)?
Is my understanding right that chrome.storage.sync is only to be used for some configuration data?
Yes, being a limited storage, it is intended for maintaining different forms of state data.
And is there a straightforward way to force sync the 'local' chrome
storage anyhow (might Firebase be an option)?
You can definitely use some external service like Firebase to save the user data and gain synchronization on different devices
I'm interested in building a small offline webapp and I'm looking for some advice. Here's the basics of what I want it to do
Create reports that, initially, will just have a name and text field
List, edit, and delete these notes
Ideally I'd like to add more fields to the reports later
Is localstorage a good option for storing this type of data locally? If so, can anybody direct me to a complete list of the commands for interacting with it in javascript? e.g. setItem, getItem, etc.
Thanks.
localstorage will work just fine for this, but don't think of it as a robust solution.. It's just a basic key/value store and won't be very performant with thousands of complex things going on.
Check out the excellent Dive into HTML5 guide on localstorage:
http://diveintohtml5.info/storage.html
Link to the localstorage apis
Yes localstorage would be perfect for you application. It would allow your application to have no need to connect to a server at all. Keep in mind that local storage does have maximums on the amount of data that can be stored.
EDIT:
Using JSON.stringify() on can convert complex javascript objects to json which can be storage and retrieved with ease inside of local storage.
I have a bit of conceptual question regarding the structure of users and their documents.
Is it a good practice to give each user within CouchDB their own database which hold their document?
I have read that couchDB can handle thousands of Databases and that It is not that uncommon for each user to have their database.
Reason:
The reason for asking this question is that I am trying to create a system where a logged in user can only view their own document and can't view any other users document.
Any suggestions.
Thank you in advance.
It’s rather common scenario to create CouchDB bucket (DB) for each user. Although there are some drawbacks:
You must keep ddocs in sync in each user bucket, so deployment of ddoc changes across multiple buckets may become a real adventure.
If docs are shared between users in some way, you get doc and viewindex dupes in each bucket.
You must block _info requests to avoid user list leak (or you must name buckets using hashes).
In any case, you need some proxy in front of Couch to create and prepare a new bucket on user registration.
You better protect Couch from running out of capacity when it receives to many requests – it also requires proxy.
Per-doc read ACL can be implemented using _list functions, but this approach has some drawbacks and it also requires a proxy, at least a web-server, in front of CouchDB. See CouchDb read authentication using lists for more details.
Also you can try to play with CoverCouch which implements a full per-doc read ACL, keeping original CouchDB API untouched, but it’s in very early beta.
This is quite a common use case, especially in mobile environments, where the data for each user is synchronized to the device using one of the Android, iOS or JavaScript (pouchdb) libraries.
So in concept, this is fine but I would still recommend testing thoroughly before going into production.
Note that one downside of multiple databases is that you can't write queries that span multiple database. There are some workarounds though - for more information see Cloudant: Searching across databases.
Update 17 March 2017:
Please take a look at Cloudant Envoy for more information on this approach.
Database-per-user is a common pattern with CouchDB when there is a requirement for each application user to have their own set of documents which can be synced (e.g. to a mobile device or browser). On the surface, this is a good solution - Cloudant handles a large number of databases within a single installation very well. However ...
Source: https://github.com/cloudant-labs/envoy
The solution is as old as web applications - if you think of a mySQL database there is nothing in the database to stop user B viewing records belonging to user A - it is all coded in the application layer.
In CouchDB there is likewise no completely secure way to prevent user B from accessing documents written by user A. You would need to code this in your application layer just as before.
Provided you have a web application between CouchDB and the users you have no problem. The issue comes when you allow CouchDB to serve requests directly.
Using multiple database for multiple users have some important drawbacks:
queries over data in different databases are not possible with the native couchdb API. Analysis on your website overall status are quite impossible!
maintenance will soon becomes very hard: let's think of replicating/compacting thousands of database each time you want to perform a backup
It depends on your use case, but I think that a nice approach can be:
allow access only through virtual host. This can be achieved using a proxy or much more simply by using a couchdb hosting provider which lets you fine-tune your "domains->path" mapping
use design docs / couchapps, instead of direct document CRUD API, for read/write operations
2.1. using _rewrite handler to allow only valid requests: in this way you can instantly block access to sensible handlers like _all_docs, _all_dbs and others
2.2. using _list and _view handlers for read doc/role based ACLs as described in CouchDb read authentication using list
2.3. using _update handlers for write doc/role based ACLs
2.4. using authenticated rewriting rules for read/write role based ACL.
2.3. filtered _changes handler is another way of retrieving all user's data with read doc/role based ACL. Depending on your use case this can effectively simplify as much as possible your read API, letting you concentrate on your update API.
I'm working on some web application and we need to store number of javascript objects in local storage. Until now we did it using cookies but we want to use one of HTML5 storage solutions because cookies data is send to server on each server call and it is a waste of resources and also it's size is very limited. The data should be stored permanently, I mean it should be available after closing the browser and opening it again.
What is the best practice to do this? Is there any way to store objects in local storage. Thanks for the assistance
In my current project I'm using PouchDB library (http://pouchdb.com/). It is a lightweight javascript database which can store data locally in browser (string, int, object etc). All stored data are still available after browser restart.
You should use it with some JS framework, in my case it is AngularJS (very simple integration).
Have a look at this link: http://slides.html5rocks.com/#web-storage
It sounds like HTML5's Local Storage is definitely a great option for you. That presentation has a lot of great info in that should help you decide on the best form of storage.
IndexedDb is a good option for storing javascript objects.
I strongly recommend you to read this -> https://developer.mozilla.org/en-US/docs/IndexedDB