javascript - How can I sync localStorage across Chrome instances (or use chrome.storage.sync without a published extension)? - S

admin管理员组

文章数量:1208155

Here is my situation: I have written a number of Chrome userscripts for my personal use. Previously, I only had one machine with one instance of Chrome on it, so I was perfectly happy to dump any persistent data into localStorage.

However, I now have multiple machines, and want to use my userscripts on Chrome on all the machines, with my persistent data coming along for the ride. Synchronizing the userscript code itself is straightforward if a bit tedious (stick it in a Bitbucket repo, then pull and manually install), but I have no idea how to synchronize my localStorage data across machines.

I have considered converting my userscripts to proper Chrome extensions and using the chrome.storage API (data stored using chrome.storage.sync apparently can be sync'd if you have a Google account connected to your Chrome instances, which I do). However, here is the issue with that for my use case:

• In order to synchronize your data, it appears that you have to publish your extension to the Chrome store.
• I don't want my extensions publically viewable on the Chrome store, since 1.) that costs money; and 2.) some of the extensions are "sensitive" in nature.
• Even if I were to spend money and thereby solve (1.), the only way I've found to put private extensions on the Chrome store is to be using Google Apps for Work or Education (cf. "Publish a private Chrome app"), and I obviously don't have a personal instance of Google Apps.

So: is there some way for me to either 1.) sync localStorage across machines directly, or 2.) use the chrome.storage.sync API without a publically published Chrome extension?

Here is my situation: I have written a number of Chrome userscripts for my personal use. Previously, I only had one machine with one instance of Chrome on it, so I was perfectly happy to dump any persistent data into localStorage.

However, I now have multiple machines, and want to use my userscripts on Chrome on all the machines, with my persistent data coming along for the ride. Synchronizing the userscript code itself is straightforward if a bit tedious (stick it in a Bitbucket repo, then pull and manually install), but I have no idea how to synchronize my localStorage data across machines.

I have considered converting my userscripts to proper Chrome extensions and using the chrome.storage API (data stored using chrome.storage.sync apparently can be sync'd if you have a Google account connected to your Chrome instances, which I do). However, here is the issue with that for my use case:

• In order to synchronize your data, it appears that you have to publish your extension to the Chrome store.
• I don't want my extensions publically viewable on the Chrome store, since 1.) that costs money; and 2.) some of the extensions are "sensitive" in nature.
• Even if I were to spend money and thereby solve (1.), the only way I've found to put private extensions on the Chrome store is to be using Google Apps for Work or Education (cf. "Publish a private Chrome app"), and I obviously don't have a personal instance of Google Apps.

So: is there some way for me to either 1.) sync localStorage across machines directly, or 2.) use the chrome.storage.sync API without a publically published Chrome extension?

• javascript
• google-chrome
• google-chrome-extension
• local-storage

Share Improve this question Follow asked Apr 10, 2015 at 17:58 senshinsenshin 10.4k77 gold badges4848 silver badges6060 bronze badges 2

• You can have an extension be unlisted, so that it only shows up if someone knows the url. For example, on my unlisted extension, under "Related"/"More from this developer", Google has a link to my publicly listed extension. But there isn't a link from the publicly listed one to my unlisted one. Would that work? – Teepeemm Commented Apr 10, 2015 at 18:59
• @Teepeemm That would probably be good enough for my purposes (I don't need this stuff to be actually hidden; security via obscurity should suffice). I'll go give this a try. – senshin Commented Apr 10, 2015 at 19:21

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 15

This doesn't really answer the question as I originally asked it, but this is what I ended up doing to solve the problem described above, so whatever.

• In the end, I abandoned the idea of using chrome.storage (the space restrictions on chrome.storage.sync were untenable) and instead wrote my extension using PouchDB, which is a Javascript implementation of CouchDB. PouchDB uses IndexedDB internally, which does have a per-extension limit by default (I think 5 MB? I didn't bother to test), but can be granted unlimited storage by setting the "unlimitedStorage" permission in the extension manifest. PouchDB's storage model is significantly superior to the chrome.storage storage model in basically every way (free revision tracking, a documented sync protocol rather than whatever voodoo chrome.storage.sync does, etc.), and the downsides (an extra dependency, need for a separate remote server [see below], etc.) were not a huge issue for me.
• I spun up a free EC2 micro instance and installed a CouchDB server on it. CouchDB is a little bit finicky to configure, but works well once that's taken care of. My EC2 instance stopped being free after a year, so I switched to Cloudant, which offers CouchDB-compatible hosting that's free if you use less than $50 worth of storage + bandwidth per month, which I do.
• I set my extension to point at my Cloudant instance, have it authenticate using plain old HTTP basic authentication (which is fine here, since I'm the only person using this extension, which means I'm free to put my password in plaintext in the extension), and have it sync with the remote instance when requested by the user.
  • The authentication approach I took here (in conjunction with the deployment strategy [see below], etc.) probably has a bunch of holes, but I don't really care; it seems sufficient to stop casual intrusions, which is good enough (I'm not dealing with important or privileged data).
• Rather than deploying my extension via the Chrome store, which seems complicated and costs money, I now have a rather more ghetto solution whereby I move my extension from my development machine to my other machines by copying the unpacked extension folder into my Dropbox folder and waiting for Dropbox to sync it to my other machines. I then load (or reload) the unpacked extension on my other machines. (This was easier than a Bitbucket-based solution [or any other Git-based solution] because my Windows machines all throw fits when I try to get anything done with Git.)
  • One downside of using Dropbox (or any other solution that involves unpublished unpacked extensions) rather than the Chrome store - Chrome pesters you about disabling non-store extensions every time you open Chrome, even if you're on the Chrome dev channel. In light of Xan's comments below, I'm probably going to take a second look at using the Chrome store as a means of deploying the extension.

A Google account comes with 15Gb of storage. Gmail, Google Docs, Google Tasks, Google Calendar, Google-Drive and chrome.storage ALL get packed into that 15Gb of Google Bucket space. More than 15Gb, if go big with Google One :) .

Extensions like "Tabs Outliner" stores a significant amount of data (on my desk, 10,000+ nested HTML lists/href list items) in ?localStorage? ... and up to 1000 backups in a Google-Drive folder, which appears private to the extension. i.e It is essentially a bottomless private folder for the Extension.

The downside: Tabs Outliner requires you to login to Google to sync the account on each machine you deploy to ... and (I think) each time there is an extension update. But publishing your extension (even privately) on CWS means that the publically registered Extension ID is recognised in your Google profile; and automatically deployed/updated from the CWS to ANY Chrome Browser where you've logged in with your Google Account. The Sync with Google-Drive is just a login away, but there may even be answers for that. (No promises ... the guy that wrote Tabs Outliner is pretty savy).

Apologies, I know this is lacking in detail. I'm considering picking up Tabs Outliner if it's Ukraine developer doesn't come back anytime soon (tumbleweeds for a few years to a paid community, but perhaps he has more pressing problems). I'm fumbling in the dark a little myself, but there area MANY good extensions - most with github source that you can view freely - which offer a model for the things we try to do.

HTH.

本文标签：