Re: [OAUTH-WG] Rename callback => callback_uri

Luke Shepard <lshepard@facebook.com> Fri, 16 April 2010 19:37 UTC

Return-Path: <lshepard@facebook.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A6A3A6BAC for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 12:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.017
X-Spam-Level:
X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvSeTu7a-Z-q for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 12:37:43 -0700 (PDT)
Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id D62303A6B83 for <oauth@ietf.org>; Fri, 16 Apr 2010 12:36:56 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3GJZ3Jl015640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Apr 2010 12:35:08 -0700
Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 16 Apr 2010 12:35:33 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Fri, 16 Apr 2010 12:35:04 -0700
From: Luke Shepard <lshepard@facebook.com>
To: Richard Barnes <rbarnes@bbn.com>, Evan Gilbert <uidude@google.com>
Date: Fri, 16 Apr 2010 12:35:02 -0700
Thread-Topic: [OAUTH-WG] Rename callback => callback_uri
Thread-Index: AcrdmsrXIafTB8XVSSmIN6UmDTmsBwAAMbaA
Message-ID: <2513A610118CC14C8E622C376C8DEC93D54D66DD35@SC-MBXC1.TheFacebook.com>
References: <9C30AE64-7DB8-4B6B-879B-61CB71BF74BB@facebook.com> <C7EC567E.322EE%eran@hueniverse.com> <2513A610118CC14C8E622C376C8DEC93D54D66DCA7@SC-MBXC1.TheFacebook.com> <CA16E5C8-7987-4D5B-9038-E705E6630A07@bbn.com> <2513A610118CC14C8E622C376C8DEC93D54D66DCF5@SC-MBXC1.TheFacebook.com> <i2pc8689b661004161205g949c17a1z245fd80199140ea4@mail.gmail.com> <E81D4800-784B-45B4-87A4-0C3960EB20C8@bbn.com>
In-Reply-To: <E81D4800-784B-45B4-87A4-0C3960EB20C8@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-16_07:2010-02-06, 2010-04-16, 2010-04-16 signatures=0
Cc: Naitik Shah <naitik@facebook.com>, OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rename callback => callback_uri
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 19:37:45 -0000

The spec officially protects against collisions: All OAuth-specific endpoints shouldn't accept extra parameters, and the protected resources need only worry about "access_token". 

The issue is softer - in this case, we are anticipating and preventing what would otherwise be a common source of developer confusion.
 
redirect_url (or redirect_uri, but we use _url elsewhere so whatever) seems the best to me too.

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com] 
Sent: Friday, April 16, 2010 12:27 PM
To: Evan Gilbert
Cc: Luke Shepard; Naitik Shah; OAuth WG
Subject: Re: [OAUTH-WG] Rename callback => callback_uri

Ok, I think I get it.  Thanks for the explanation.

It seems we have a collision of layers here!  When OAuth parameters  
are being passed as request parameters (GET or POST), they can collide  
with parameters being used by an application (e.g., for JSONP).  In  
effect, encoding OAuth in this way creates a set of "reserved words"  
that applications can't use.

In the short run, it's probably an OK hack to rename parameters to  
something unlikely to collide, e.g., "oauth_*".  (Note: This applies  
to all OAuth parameters, not just "callback").

In the long run, though, doesn't this problem kind of argue that we  
shouldn't be passed as application-layer things (request parameters),  
but rather as HTTP-layer things, e.g., in an Authorization header?

--Richard



On Apr 16, 2010, at 3:05 PM, Evan Gilbert wrote:

> We should use the same name in the User-Agent and Web Callback  
> flows. Also, although the authorization server won't be allowing  
> JSONP requests, "callback" has become a bit of a defacto standard  
> for JSONP and it would be nice to use a term that isn't overloaded?
>
> Can we make them both "redirection"? Even better, maybe  
> "redirect_uri"?
>
> On Fri, Apr 16, 2010 at 9:50 AM, Luke Shepard  
> <lshepard@facebook.com> wrote:
> Facebook API requests are protected resources. They can be called  
> either in a browser or in a server-to-server environment.
>
> For example, a JSONP call for my name looks like this:
>
>        https://api.facebook.com/restserver.php?api_key=361900759629&call_id=1271436355034&callback=FB.RestServer._callback&format=json&method=fql.query&query=SELECT%20name%20FROM%20user%20WHERE%20uid%3D2901279&v=1.0
>
> The output (you can play with it here: http://fbrell.com/fb.api/everyone-data 
>  ):
>
>        FB.RestServer._callback([{"name":"Luke Shepard"}]);
>
> If we want that protected resource to take an access token as well,  
> then it would look like:
>
>        https://api.facebook.com/restserver.php?....&callback=FB.RestServer._callback&access_token=ACCESS_TOKEN
>
> The "callback" parameter is used pretty universally for JSONP  
> requests. For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/
>
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Friday, April 16, 2010 9:10 AM
> To: Luke Shepard
> Cc: Eran Hammer-Lahav; Naitik Shah; OAuth WG
> Subject: Re: [OAUTH-WG] Rename callback => callback_uri
>
> Could you clarify a little more the environment in which this
> confusion arose?  What do you mean when you say "The protected
> resource typically accepts 'callback' as a parameter to support
> JSONP."?  What sort of software are you including in this?
>
> --Richard
>
>
> On Apr 15, 2010, at 5:41 PM, Luke Shepard wrote:
>
> > We already had one developer try it out and get confused because the
> > server tried to treat the callback URL as a JSONP callback.
> >
> > The protected resource typically accepts "callback" as a parameter
> > to support JSONP. If a developer accidentally passes in callback
> > there (maybe they got confused) then the server can't give a normal
> > error message - instead it needs to either detect that it looks like
> > a URL or otherwise reject it.
> >
> > On a related note, I think it's more confusing calling it something
> > different in the user-agent flow (redirector) when it's essentially
> > doing the same thing.
> >
> >
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > Behalf Of Eran Hammer-Lahav
> > Sent: Thursday, April 15, 2010 5:37 AM
> > To: Naitik Shah; OAuth WG
> > Subject: Re: [OAUTH-WG] Rename callback => callback_uri
> >
> > I don't think it is that confusing. Its a completely different
> > context from where JSON-P is used (note that in the User-Agent flow
> > it is called something else).
> >
> > EHL
> >
> >
> > On 4/10/10 12:35 PM, "Naitik Shah" <naitik@facebook.com> wrote:
> >
> > With the simplified params, the callback url parameter is now just
> > "callback". Since most major API providers already use "callback" to
> > signify JSON-P callback, can we rename this to "callback_uri"? This
> > will help avoid collisions and confusion.
> >
> >
> > -Naitik
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>