On Fri, Apr 16, 2010 at 6:08 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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.
Sure, but I think we are dealing with two different issues here. One is allowing query parameters on callbacks and authz server endpoints, and the other is parameter prefixes. Do we agree on query parameters being allowed on all URLs? Marius > > 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
