BTW, making this change includes dropping the client state parameter and allowing clients to add their own state parameter to the callback.
EHL On 4/16/10 7:34 AM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: First, this argument only holds for callbacks, not for the authorization endpoint. 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. I'm sure that the Drupal community will find a solution if there are valuable OAuth 2.0 resources they want to access. 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. 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
