replication with browserID auth?

[timbertson]

Less of a bug, more of a request for help / ideas. I couldn't find a newsgroup, but let me know if there's a better avenue for this.

I have a couchApp I'm writing, and I want to be able to have the following setup:

• upstream couch, hosted somewhere globally available (with a private DB per user)
• local couch (running on localhost), for when network is unavailable (with only the user's DB)

I'd like to use replication to sync the two when the network is up, but can't figure out how to do this securely. Obviously, I'm using browserid on the hosted couch. For the local couch I haven't decided if auth is necessary. The local couch should not be exposed to the internet, so it will have to be the one to initiate replication.

I can do this hackily right now if I grab the cookie header from a browser session auth'ed into the hosted couch, and put that header in the replication parameters that I submit to my local couch. I do this by manually using firebug, and I can't see any way to make this happen automatically (certainly not without a wrapper program running locally that can get around same-origin restrictions).

Would it be possible to somehow use browserID locally, but initiate an assertion to be generated for myhostedcouch.com instead of localhost? And then further to that, I'd need a way to send that assertion to the upstream couch in the replication paramaters (instead of sending a cookie, because obviously I couldn't generate a cookie locally that would be recognised by the upstream server). Presumably, a header would suffice but this would need to be explicitly added to browserid_couchdb.

So firstly, is that a plausible thing to look into? And secondly, is it an intrinsically bad idea (because it leaves a glaring security hole, for example).

Are there any other good ways to replicate with a couch that only uses browserid for auth?

[jhs]

That's very interesting. Since BrowserID automatically creates a normal /_user document, you could set a password too and use HTTP basic auth.

Making the replicator support BrowserID natively would require a patch against CouchDB but it sounds worthwhile to me.

[timbertson]

True. I didn't want to have to deal with user's passwords, but that could be a way to enable it. Might be pretty confusing having both though.

I'm interested about the technical side of having the replicator support browserID. I don't know much about it, but would it be technically possible for a site on localhost to collect an assertion for a different audience (i.e then the localhost couch could include an assertion with the audience of "myhostedcouch.com" as part of the replication). It sounds like the assertion should be collectable from anywhere, but I don't know if/how the browserID UI / service would let that happen.

[timbertson]

I opened a discussion over on mozilla.dev.identity about this: http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/8ce4ca241914b1b4

It seems like allowing couchdb to accept both assertions from its configured domain and from localhost might be a reasonable solution for this case. Would that be possible? I think it would require a configuration key, something like browserid.allowable_audiences as an array of (possibly wildcarded) domains.

But even if that were implemented, there's still the trouble of running replication from a local couch, which obviously wouldn't go through the /_browserid url to set up its session. If the couchdb "Cookie" authentication could be extended to accept some sort of BrowserID header (including an assertion & audience, instead of a generated cookie token) then it sounds like it could work, but that may be a lot of wishful thinking - I've no idea how possible that would be to implement.

Alternatively, if (just) the /_browserid resource were exposed via CORS ( https://issues.apache.org/jira/browse/COUCHDB-431 ) then localhost could perhaps hit /_browserid in a precursor to the replication trigger in order to grab a valid cookie, but I've no idea if that would create other security holes.