Is there anything other than pragmatism that makes the temporary 302'sso prolific? I see it in a bunch of places where permanent 301 redirects would seemingly make more sense.
Also: Auto redirects as a side-effect to POSTs are forbidden in HTTP 1.1, but that still is what we have to do in protocol dancers like OAuth and OpenID. I could be confused, but it seems there is (no easy) way to implement any dancing protocol without breaking HTTP 1.1! Do I miss something obvious? I like pragmatism :) but how would OAuth implementations fare if browser manufacturers started enforcing this aspect of the HTTP standard? I guess the user experience could deteriorate quite badly? Hans On Mon, Nov 24, 2008 at 10:14 AM, Joseph Smarr <[EMAIL PROTECTED]> wrote: > We recently had to debug a fairly subtle bug with one of our OAuth > Consumers, and it's not clear there's a "quick fix" we can make in OAuth to > address it, so I thought I'd share our experience in the hopes that it helps > others and/or makes its way into some OAuth guides in the future: > > The punchline is: if someone is making an OAuth-signed API request to one > of your URLs, and you return a 302 (e.g. because you changed your URL > structure), the signature will probably fail to match, because the consumer > will use the pre-redirected URL and the provider will use the > post-redirected URL. > > The context: we recently changed our URL structure in Plaxo Pulse (we moved > from pulse.plaxo.com/pulse/... to www.plaxo.com/... for all our pages), so > we added some apache rewrite rules to issue 302s for all the old paths to > the new versions. In the course of normal web browsing, this works fine and > is transparent to the user. But we had some OAuth consumers that had > hardcoded the old URLs into their client code, and their requests started > failing. It turned out to be because our server was issuing a 302, the > client curl lib would follow redirects, and so the request would go through, > but the client had generated their signature base string with the > non-redirected URL and the provider generated the signature base-string with > the post-redirected URL (being blissfully unaware of the pre-redirected > version), so the signatures didn't match. Once we figured this out, it was > pretty easy to tell the client to update their URLs, but we were lucky that > the URLs weren't say in client software that couldn't be easily patched. > > It's hard to see how to avoid this problem, other than a) not to ever > change URL structure of OAuth provider URLs, or b) have consumers watch for > 302s and recompute their signature and re-send the request if they see one. > In general, both seem infeasible in practice, so I think at best we should > document this as a "known gotcha" to look for when debugging code. > > Thanks, js > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
