On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav <[email protected]> wrote: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:[email protected]] >> Sent: Thursday, July 01, 2010 2:21 PM > >> >> 2. Greatly reduce the chances of a conflict with a query parameter >> >> used by an authz server endpoint or client redirect_uri. >> > >> > There should not be any conflict. Either it has been registered or uses x_. >> >> There can be. Here is the example I gave earlier in another thread. >> MediaWiki uses the 'title' parameter. Some OAuth extension may register >> and use this same name and this will prevent MediWiki from being able to >> support that extension. > > I think this discussion (which we spent many days on already) boils down to a > philosophical approach to the level a new protocol should accommodate the > broken environment in which it is expected to be deployed. > > I think MediaWiki should change the way it treats the OAuth endpoints to > isolate them from the rest of the platform. When receiving an OAuth request > (with such an OAuth 'title' parameter), the platform can rename all the OAuth > parameters to oauth_ internally and proceed to add its own parameters without > conflicts.
When receiving an OAuth request MediaWiki will have two title parameters, the damage is already done. > While this approach might not be trivial, it is clearly possible. I think > there is a larger question of how OAuth is used in a MediaWiki installation, > and how it can accommodate some of the other requirements such as SSL. > > I do not consider making MediaWiki's deployment of 2.0 easier an important > consideration. MediaWiki is just an example. Drupal is another. My guess is that most PHP frameworks have this issue. >> >> Cons: >> >> >> >> 1. Slightly longer parameter names. >> > >> > Also, messy, ugly, opens the door to extensions without review. >> >> I don't get the last part, skipping reviews. As for beauty, that's relative >> ;-) > > If we approve a blanket "prefix_" extension, we lose the ability to review > individual parameters within that prefix. I think you mentioned that the review is meant to prevent name conflicts, nothing else. Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
