chicken-users
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]