couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Higham <>
Subject Re: How does OAuth support, or custom headers, work in the replicator?
Date Mon, 21 May 2012 18:06:38 GMT

Here's how the secrets and tokens map to the terms in the article:

OAuth Client token & secret -> couchDB OAuth Consumer key & consumer Secret
OAuth Access token & token secret -> couchDB Token & token secret

Signature method is pretty much always HMAC-SHA1

On Monday, 21 May 2012, Jens Alfke wrote:

> On May 20, 2012, at 4:02 AM, Martin Higham wrote:
> > - The fields in the replication structure are fine if you want CouchDB to
> > replicate to CouchDB, but I think in your case you want to OAuth requests
> > from a client to CouchDB so you will want to sign each request yourself.
> Not quite: I'm implementing what is effectively a client-side CouchDB
> server*. It has its own replicator, which may need to authenticate to the
> remote server it's replicating with. I'm trying to implement OAuth for
> that. So it's actually a combination of the two — the replicator obviously
> acts as a client to the remote server, but TouchDB implements most of the
> CouchDB REST API for the local app to interact with, and that extends to
> the schema of replication documents.
> So I think my new question is: Given the fields "consumer_secret",
> "consumer_key", "token_secret", "token" and "signature_method", how do I
> use them to sign a request? I'm an OAuth dummy but fairly knowledgeable
> about security/crypto, so a link to the right spec or section thereof would
> suffice :)
> —Jens
> *

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message