[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


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
     Content-Type: application/x-www-form-urlencoded
     Authorization: OAuth realm="Example",

The above is a copy/paste from the RFC:

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 @@
                                     eq? default-unparser))
                (unparsed-value (sprintf "~A ~A"
-                                        (symbol->http-name auth-scheme)
+                                        (symbol->string auth-scheme)
                                         (unparser (get-params (car
           (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?



reply via email to

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