On Tue, Jul 6, 2010 at 10:24 PM, Marius Scurtescu <[email protected]> wrote: > On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams <[email protected]> wrote: >> For section 6.2 (query parameters on the end-user authorization and >> token endpoints), this should not be an issue for WordPress. >> >> For section 6.3 (header parameters), this should not be an issue for >> WordPress. > > This is not an issue because whatever query parameter WordPress is > using does not collide with the core OAuth 2 parameters? Or because > WordPress is not using query parameters?
Neither: because WordPress is extensible enough to allow for this kind of functionality. WordPress uses query parameters. A WordPress plugin that enables OAuth, though, would have to register new URL handlers with WordPress to act as the token and end-user authorization endpoints. Having done so, the plugin would then have complete control over how to behave under any query parameters, entity-body contents, or headers: core, extension, site specific or otherwise. As evidence, I have written such plugins for OAuth 1.0a, OAuth WRAP, and OAuth 2.0-draft-05. I would be surprised if the story were different for MediaWiki and Drupal; I naively believe a similar plugin could be developed for each of those platforms that would avoid query parameter collision. "Naively" because I am unfamiliar with both of those platforms. Mike --mdawaffe _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
