couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joan Touzet (JIRA)" <>
Subject [jira] [Created] (COUCHDB-1144) oauth requests with URL realms result in function_clause error in HTTP request
Date Thu, 28 Apr 2011 06:47:03 GMT
oauth requests with URL realms result in function_clause error in HTTP request

                 Key: COUCHDB-1144
             Project: CouchDB
          Issue Type: Bug
          Components: HTTP Interface
    Affects Versions: 1.0.2, 1.1
         Environment: OSX - branch 1.1 - r1095237
            Reporter: Joan Touzet
            Priority: Critical

As illustrated in this Wireshark packet dump, lines 53ff, any OAuth request with a URL as
the realm will return a 500 error: 

Erlang stacktrace is similar to:

[error] [<0.189.0>] function_clause error in HTTP request [Wed, 27 Apr 2011 23:31:46
GMT] [info] [<0.189.0>] Stacktrace:
[{oauth_uri,decode, ["://","ptth"]},
                                {proc_lib,init_p_do_apply,3}] [Wed, 27 Apr 2011 23:31:46 GMT]
[info] [<0.189.0>] - - 'PUT'
/test_c_project/16f74c25-d641-4710-8f38-18295a8a69b1 500

Chatted with benoitc today and he suggested this may be because the realm is not being properly
encoded before being passed on.

By default, some OAuth libraries such as python's popular oauth2 library always set the realm
of a request to the URL of the resource being accessed, such as http://localhost:5984/ . (In
fact, oauth2 library does not support overriding this setting.) The OAuth spec @
also shows realms specified as URLs.  RFC5849 states "The OPTIONAL "realm" parameter MAY be
added and interpreted per [RFC2617] section 1.2.", which in turn says the realm is any quoted-string.

It seems that this may already be fixed in trunk simply because trunk has a newer version
of the upstream erlang-oauth.

A JS test could be added in futon to validate this by modifying function oauthRequest to accept
a realm parameter, then passing that down to OAuth.getAuthorizationHeader on line 56. 

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message