On Thu, Jul 1, 2010 at 4:21 PM, Eran Hammer-Lahav <[email protected]> wrote: > > >> -----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.
That is not realistic. >> > 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. This has nothing to do with the price of hosting. On dedicated servers PHP frameworks have the same issue. Chances for a collision are still small, so I am not saying that no prefixes will break all PHP frameworks, just that the chances that some of them will have collisions is getting higher. Also, not only existing frameworks can potentially have problems. A brand new OAuth 2 server implementation may decide to use query parameters on the published endpoints, for whatever reason. They can chose names so there are no collisions with core and existing extensions but there is no guarantee that newer extension will no introduce one. We are going in circles. The only reason I brought this up again is because of the extensions, feel free to ignore this thread. Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
