You should also accept 'oauth_token'. That's one place a prefix makes sense because there is no telling what a protected resource URI might look like.
EHL On 4/16/10 6:24 PM, "Luke Shepard" <lshep...@facebook.com> wrote: Oh, and fwiw, we dropped the prefix EVERYWHERE. So even the protected resource just takes "access_token", not "oauth_access_token", for consistency. From: Luke Shepard Sent: Friday, April 16, 2010 6:23 PM To: 'Eran Hammer-Lahav'; Marius Scurtescu Cc: OAuth WG Subject: RE: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy So, I originally favored the prefix, as I couldn't see how you would not do it. But I've recently implemented OAuth prototype and written some apps against it, and I have to say, I like not having the prefix. Most developers don't care that they are using OAuth - they just want to talk to a service. The prefix sort of beats them over the head with it, without much benefit. It's one less thing to scare new developers. So, I'm in favor of no prefix. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, April 16, 2010 6:08 PM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy We are going in circles. We are just not going to agree on this. I don't think we should have a parameter prefix for OAuth-specific calls, you think we should. Time to let other people express their view on this. I'm sure both of us can live with both options. EHL On 4/16/10 5:58 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: On Fri, Apr 16, 2010 at 7:34 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > First, this argument only holds for callbacks, not for the authorization > endpoint. And why is that? This argument applies exactly the same way to the authorization endpoint. The same Drupal site can also be an OAuth 2.0 Authorization Server. Basically any framework which does dispatching of requests based on query parameters will require that endpoints (or callbacks) have query parameters. > Since this problem is easily solved with a simple web server > configuration, I don't think it is as bad as you make it sound. Please read my example again. This *cannot* be solved with any kind of web server configuration. Ideal server configuration will make it appear that no query parameters are used, but behind the scene they are. Query parameters are needed on all endpoints, visible or not. > I'm sure > that the Drupal community will find a solution if there are valuable OAuth > 2.0 resources they want to access. That's close to impossible. Do you really expect them to change the fundamental architecture of Drupal just to support OAuth? And the main reason for that architecture is how PHP works and what is available with shared hosting, so I guess many other similar frameworks will work like this. > However, I don't have an objection to a prefix for callback parameters since > those are not purely protocol endpoints but client endpoints with potential > existing semantics. We already have oauth_token for accessing a protected > resource using query parameters (for the same reason). > > But this argument does not extent to the authorization endpoint. Please read above, it does. Marius > > EHL > > > On 4/15/10 9:10 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: > > On Thu, Apr 15, 2010 at 6:39 PM, Evan Gilbert <uid...@google.com> wrote: >> >> On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu <mscurte...@google.com> >> wrote: >>> >>> OK, here is a concrete example: >>> >>> A Drupal (popular PHP based CMS) based web site wants to become an >>> OAuth 2 client. Among other things it needs to implement a callback >>> endpoint. >>> >>> Ideally this endpoint would look something like: >>> http://example.com/oauth/back >>> >>> Depending on what web server is used and how it is configured, the >>> above URL may not be possible. Drupal is dispatching all requests >>> through the main script and the path of the endpoint is passed as a >>> query parameter. Normally the above URL is seen as: >>> http://example.com/index.php?q=oauth/back >>> >>> The cleaner http://example.com/oauth/back is achieved with Apache URl >>> rewriting, but if Apache is not available or configured to support >>> that, you are stuck with the ugly query parameters. >>> >>> In the unlucky case the registered callback, and the actual callback >>> used in messages, is "http://example.com/index.php?q=oauth/back";. This >>> callback has a query parameter, it is not used for state, and it is >>> not an extension. >>> >>> It so happens that "q" will not conflict with any of the existing >>> OAuth 2 parameters, but you can see the potential issue. >>> >>> Now, even if Apache is available and URL rewrites work, so the nice >>> callback is used, a collision would still happen if "q" was used by >>> OAuth 2. Apache rewrites "/oauth/back", but the Drupal dispatcher >>> always sees "/index.php?q=oauth/back", so another q parameter would >>> break things. >> >> We should ask Drupal to change their query parameter to drupal_q. > > And every single framework that does dispatching based on query parameters > :-) > > >>> I do realize that a prefix will not solve ALL collisions and it is >>> also not solving the extension question, but I still think makes a big >>> difference. >> >> This use case makes sense, but do we know of any existing conflicts? >> Very few web servers have this restrictive a URL parameter policy - I >> think >> I'm OK losing compatibility with future web servers that reserve the >> "callback" parameter for other purposes. > > My guess is that most PHP frameworks will have a similar problem, they > will require query parameters. This is not a web server issue, but a > framework issue. > > Not only "callback" can cause a collision, but every single OAuth 2 > parameter. > > > Marius > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
