> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Thursday, July 01, 2010 2:59 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter > names > > 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.
Yes, they might need to change their platform to support it. I'm ok with that. > > > 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. And they will need to find ways to accommodate OAuth 2.0 endpoints. Every web server provides sufficient tools to rewrite requests. I don't have much sympathy for the $5 hosting user. > >> >> 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. The review is meant to prevent name collision and people doing really stupid things. Part of name collision is also to make sure that people use proper names... EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
