Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters)

From: Peter Wolanin <[email-masked]>
Date: Mon, 9 May 2011 22:15:47 -0400

I think it's perfectly reasonably - if inside the service you need to
rewrite the URI, it's not hard to preserve the original as an extra
header or ENV.

We have a HMAC-sha1 implementation in production where the load
balancer (nginx) may rewrite the URI before passing it to a java app
that authenticates the request, so the original URI is set as a new
header and used to calculate the HMAC in java.

-Peter

On Mon, Apr 18, 2011 at 3:26 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> I would like to drop all the request URI parameters normalization logic and
> just use the raw request URI instead. A year ago during the discussion on my
> Token authentication scheme (which had that behavior specified), some people
> raised the issue that access to the raw request URI isn’t always possible on
> the client or server. This feels like a limitation that is no longer a real
> problem for any modern web development environment.
>
>
>
> If you know of actual deployment issues with using the raw request URI
> instead of the parameter parsing and sorting voodoo, please let me know.
> Otherwise, the next draft will drop that entire section.
>
>
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
[email-masked] : 978-296-5247

"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 May 2011 11:49:31 -0400

These could be solved and the whole normalization process thrown out by
just restating the string that you signed. It's then up to the server to
decide if they want to reparse and validate the request or not, but it
gets around url rewriter problems, which I've had definite trouble with
in my deployments.

Most of the signature problems I've seen in OAuth1.0 stem from the fact
that the client and the server effectively have to guess the base string
that the other signed by rebuilding it based on the best information
that they have. This is all well and good when you've got a custom
internet-facing endpoint and you have complete control over the whole
stack, but URL rewriters (for example) wreak havoc with these
assumptions. For instance, in my Elgg implementation of OAuth, I had to
put in workaround code to tell it to ignore some extra input variables
that Elgg sets on all requests. By the time it gets to my code, I have
no way of telling if the system injected them or if they're in the
original URI request at all, so I have to make my best guess and go with
that.

Yes, it inflates the request size to copy the base string over
explicitly, but that's a particular cost I'd be willing to pay for such
explicit clarity.

 -- Justin