[
https://issues.apache.org/jira/browse/COUCHDB-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-1144:
---------------------------------
Priority: Minor (was: Critical)
Description:
As illustrated in this Wireshark packet dump, lines 53ff, any OAuth request
with a non-percent-encoded URL as the realm will return a 500 error:
http://friendpaste.com/3vXPjHP6s7dLZjsj7DOfSH
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, ["://127.0.0.1:5984","ptth"]},
{oauth_uri,param_from_header_string,1},
{oauth_uri,
'-params_from_header_string/1-lc$^0/1-0-',
1},
{couch_httpd_oauth,serve_oauth,3},
{couch_httpd,authenticate_request,2},
{couch_httpd,handle_request_int,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}] [Wed, 27 Apr 2011
23:31:46 GMT] [info] [<0.189.0>] 127.0.0.1 - - '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 @ http://oauth.net/core/1.0/ 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.
was:
As illustrated in this Wireshark packet dump, lines 53ff, any OAuth request
with a URL as the realm will return a 500 error:
http://friendpaste.com/3vXPjHP6s7dLZjsj7DOfSH
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, ["://127.0.0.1:5984","ptth"]},
{oauth_uri,param_from_header_string,1},
{oauth_uri,
'-params_from_header_string/1-lc$^0/1-0-',
1},
{couch_httpd_oauth,serve_oauth,3},
{couch_httpd,authenticate_request,2},
{couch_httpd,handle_request_int,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}] [Wed, 27 Apr 2011
23:31:46 GMT] [info] [<0.189.0>] 127.0.0.1 - - '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 @ http://oauth.net/core/1.0/ 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.
Summary: oauth requests with non-percent-encoded realms result in
function_clause error in HTTP request (was: oauth requests with URL realms
result in function_clause error in HTTP request)
> oauth requests with non-percent-encoded realms result in function_clause
> error in HTTP request
> ----------------------------------------------------------------------------------------------
>
> Key: COUCHDB-1144
> URL: https://issues.apache.org/jira/browse/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: Minor
>
> As illustrated in this Wireshark packet dump, lines 53ff, any OAuth request
> with a non-percent-encoded URL as the realm will return a 500 error:
> http://friendpaste.com/3vXPjHP6s7dLZjsj7DOfSH
> 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, ["://127.0.0.1:5984","ptth"]},
> {oauth_uri,param_from_header_string,1},
> {oauth_uri,
> '-params_from_header_string/1-lc$^0/1-0-',
> 1},
> {couch_httpd_oauth,serve_oauth,3},
> {couch_httpd,authenticate_request,2},
> {couch_httpd,handle_request_int,5},
> {mochiweb_http,headers,5},
> {proc_lib,init_p_do_apply,3}] [Wed, 27 Apr
> 2011 23:31:46 GMT] [info] [<0.189.0>] 127.0.0.1 - - '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 @ http://oauth.net/core/1.0/ 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: http://www.atlassian.com/software/jira
