I am using pouchdb with sync gateway to sync documents from Couchbase to the browser.
Using pouchdb inspector the user can make changes to these documents.
So, my question is, is there a way that we can stop user from modifying the document via pouchdb inspector?
Also, even if the user modifies the document via pouchdb inspector, is there a way that I can stop this updated document to be synced back to the Couchbase server?
Please let me know your thoughts on this.
Short answer: No.
Slightly longer answer: The user is the "admin" of their local data in a web browser. They have absolute power over the pouch, and you can't take it away.
Validation functions might help you out though.
http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html
or
http://guide.couchdb.org/draft/validation.html
Your function should look for _delete === true on the document or something similar and throw({forbidden : message}).
You can add these to the PouchDB. Unfortunately the user could just delete the validation document, then delete the other documents.
If you added it to the CouchDB, it wouldn't prevent users from messing with the pouch, but the deletions wouldn't sync to the couch.
Related
So, I am working on a project(building a chrome extension) that requires data to be stored on the local machine of the user. The size of data is quite large hence I thought of using IndexDB for this purpose.
My Question is whether is it possible to connect a chrome extension with IndexDB and query the database at the same time??
If Yes, Then how can I integrate them. In which file(popup.js or background.js or any other file) should I include the source code for creating the database.
I want the code for creating the database to run only once. After that I only want to update or delete data only.
If No, then is there any other way to achieve this?? The data is large hence I cannot store data in local storage.
Any paper, online material, advice or method from chrome developers or any other valid site would be helpful. Any example would help me alot.
Thankyou.
You can store tons of data in any HTML5 storage (including IndexedDB or localStorage) and chrome.storage.local with "unlimitedStorage" permission.
HTML5 data is stored per URL origin and each extension has its own one that looks like chrome-extension://id where id is a 32-character string that is the extension's id. In Firefox the origin looks like moz-extension://id.
Extension's own HTML5 storage:
can be accessed in any extension page (popup, options, background) just like you would do it in a web page, there are no differences.
cannot be accessed in a content script as it runs in a web page and thus can only access HTML5 storage of the web page's URL origin.
chrome.storage.local can be accessed in any extension page and in a content script.
No need for special event to create/upgrade your IndexedDB storage - it'll happen automatically if needed - simply open it as shown in the documentation whenever you need to access it and your onupgradeneeded callback will be invoked in case there was no DB or it was outdated.
Use a wrapper library for IndexedDB that provides a simplified syntax. Some are listed in the documentation, but you can probably find better ones yourself.
I am looking through the code for a chrome extension i use to see what data is reported back to devleoper/mother-ship. I see that the extension's code saves some info using 'chrome.storage.sync.set' which of course makes sense as the variables that are stored there are available to me not matter what computer I load the extension on.
My question is... does the developer have access to this data? I would guess not but wanted to make sure. I have been looking for other code that posts data or does something that could send data back to developer but this was the only thing that looked suspicious so far.
No, developer cannot access chrome.storage.sync data and no one can read this except you.
This location is access controlled by
User
Extension
Infact any other extension can not read other extension's data. You can think about this storage similar to localstorage.
Now, If I ask you a question
Does the website developer has access to different values stored in user's local storage ?
The answer is No. Developer can control what to save in this storage and the values are user specific and they remain on user's machine.
However, this comes with a catch. You have to look out for code like this in the extension:
chrome.storage.sync.get('key', function(obj) {
// Make ajax to upload the key value pair
});
But by default, developer do not have access.
Could a chrome extension be made that maintains a bitcoin wallet while also making it easy for web stores to integrate a one-click purchase experience.
Suppose a button on a webpage is clicked. Is it possible for that to trigger a function call to the chrome extension to send bitcoins?
Obviously letting webpages unlimited access to chrome extensions would never have been designed. But is there some way to make this work securely?
Chrome extensions can insert arbitrary code into web pages (content scripts).
Content scripts are JavaScript files that run in the context of web
pages. By using the standard Document Object Model (DOM), they can
read details of the web pages the browser visits, or make changes to
them.
This code can communicate with the original web page via the DOM and with the rest of the extension via message passing.
In theory, this should suffice. But make it secure, please.
Multibit provides an external application solution
Clicking on a "bitcoin:" protocol URI in Chrome (or any other browser) will transfer the URI over to MultiBit (v0.3+), starting the application if necessary. This approach removes the need for private keys to be held (and potentially shared) within the browser.
This is very dangerous because a single security hole in Chrome could allow any website to empty your wallet.
First, any payment have to be confirmed with the wallet password. But, as that password is typed inside Chrome itself, it might be possible for an attacker to read that password.
In fact, there are so many security issues to solve that I think it's better to let the bitcoin client do that job.
What should be done is a way for any software to ask the bitcoin client for a transaction. The first idea that comes to mind is using DBus.
That way, the Chrome extension would only have to transform any bitcoin address by a button which calls a DBus method.
The blockchain.info Bitcoin Wallet provides some support for this
by using navigator.registerProtocolHandler and Bitcoin URI's. Unfortunately it only works in firefox at present.
From my experiences so far, I've concluded that the HTML5 Manifest scheme was really terribly designed.
My site serves a manifest file when a user is logged in. Unfortunately, when they log out, they can still access the cached protected materials. Can anyone think of a way to fix this?
A manifest file is designed to take a website offline and still be able to navigate. It essentially just tells the browser to download and keep that stuff in cache. If your adding secret stuff to the manifest and the user goes offline, he needs to be able to still access it - or whats the point of having a special logged-in-manifest-file if he has to be loggedin (therefor online)?
You could add javascript that checks if the user is online again and if he is, tries to validate the "login state" and redirects or removes the secret stuff from localstorage (if you would use localstorage to save the "secret" stuff and javascript to display it instead of a manifest file )
Lets say the secret stuff is an image and you are not using a manifest file, but just displaying images when the user is logged in and its crusial, the user cant view that image after logout, you would need to set the http headers to no-cache and cache-expire to some random date of the past, so that a normal user would see it anymore. Problem then is, that the image is downloaded everytime somebody visits the website..
You need to approach the HTML5 Application Cache in a different way. It is not useful for caching server-side dynamically generated pages, especially those that require a login to reach. The Application Cache has no concept of logins, nor securing a page from somebody with a different/no login.
It is much more appropriate for an AJAX-based site, where all HTML/CSS/JavaScript is static and registered in the Application Cache, and data is instead fetched via AJAX then used to populate pages. If you need to cache data in the application for offline use, then use one of the offline data storage mechanisms such as Local Storage/Session Storage, or IndexedDB, for data.
You can then make your own judgement on how much data you want to cache offline, since there's no way to validate a login without making a call to the server that is naturally inaccessable whilst offline.
What if when the user logs out or is not logged in they get a manifest with only network:*
I'd like to try my hand at some Chrome Extension Development. The most I have done with extensions is writing some small Greasemonkey scripts in the past.
I would like to use localStorage to store some data and then reveal the data on a extension button click later on. (Its seems like this would be done with a popup page)
How do I run a script everytime a page from lets say http://www.facebook.com/* is loaded?
How do I get access to the page? I think based off my localStorage requirement I would have to go down the background_page route (correct?) Can the background page and popup page communicate across the localStorage?
UPDATE:
I'm actually looking to learn the "Chrome way". I'm not really looking to run an existing Greasemonkey script
Google actually has some pretty good documentation on creating extensions. I recommend thoroughly reading the following two articles if you haven't already done so:
http://code.google.com/chrome/extensions/getstarted.html
http://code.google.com/chrome/extensions/overview.html
If you want to give your extension access when the user browses to Facebook, you'll need to declare that in the extension's manifest.
Unless you're wanting to save data beyond the life of the browser process, you probably don't need to use local storage. In-memory data can just be stored as part of the background page.
Content scripts (which run when you load a page) and background pages (which exist for the duration of the browser process) can communicate via message passing, which is described here:
http://code.google.com/chrome/extensions/messaging.html
Overall, I'd suggest spending some time browsing the Developer's Guide and becoming familiar with the concepts and examples.
Chrome has a feature to automatically convert greasemonkey scripts to extensions!