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 On Mon, 2011-05-09 at 22:15 -0400, Peter Wolanin wrote: > 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 <e...@hueniverse.com> > 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
