[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-users] OAuth 1.0 Authorization Header
From: |
Andy Bennett |
Subject: |
[Chicken-users] OAuth 1.0 Authorization Header |
Date: |
Tue, 23 Oct 2012 00:20:18 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7 |
Hi,
I've been writing an OAuth 1.0 egg.
One of the ways of passing the OAuth protocol parameters to the server
involves the HTTP Authorization header thusly:
-----
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
-----
The above is a copy/paste from the RFC:
http://tools.ietf.org/html/rfc5849#section-3.1
I want to talk about that word "OAuth" that appears immediately after
"Authorization: ".
HTTP specifies that that word is case-insensitive:
-----
"HTTP provides a simple challenge-response authentication mechanism that
MAY be used by a server to challenge a client request and by a client to
provide authentication information. It uses an extensible,
case-insensitive token to identify the authentication scheme, followed
by a comma-separated list of attribute-value pairs which carry the
parameters necessary for achieving authentication via that scheme."
-- RFC2617, section 1.2
-----
...and therefore when the intarweb egg unparses that header and converts
the auth-scheme from a symbol to a string it also converts whatever is
passed in into title case using intarweb's symbol->http-name.
That is entirely reasonable and conforms with the standard.
However, this results in my OAuth Authorization header looking like this:
-----
Authorization: Oauth oauth_signat...
-----
...and this causes at least Dropbox's OAuth implementation to complain
that the OAuth request is invalid.
To work around this I have patched my copy of the intarweb egg thusly:
(sorry if it doesn't copy/paste well)
-----
diff -upr intarweb.orig/header-parsers.scm intarweb/header-parsers.scm
--- intarweb.orig/header-parsers.scm 2012-10-23 00:09:28.266118261 +0100
+++ intarweb/header-parsers.scm 2012-10-23 00:05:39.071326856 +0100
@@ -823,7 +823,7 @@
(authorization-param-subunparsers)
eq? default-unparser))
(unparsed-value (sprintf "~A ~A"
- (symbol->http-name auth-scheme)
+ (symbol->string auth-scheme)
(unparser (get-params (car
headers))))))
(loop (cdr headers) (cons unparsed-value result))))))
-----
This preserves the case of the symbol passed in by the API user.
Whilst this results in an intarweb that still complies with the
standard, I wonder if there is a better way of tackling this?
Regards,
@ndy
--
address@hidden
http://www.ashurst.eu.org/
0x7EBA75FF
- [Chicken-users] OAuth 1.0 Authorization Header,
Andy Bennett <=