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

From: Naitik Shah <[email-masked]>
Date: Sat, 10 Apr 2010 12:35:52 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 05:37:02 -0700

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" <[email-masked]> wrote:

-Naitik
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Luke Shepard <[email-masked]>
Date: Thu, 15 Apr 2010 14:41:39 -0700

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: [email-masked] [mailto:[email-masked]] 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

EHL

-Naitik

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 15:15:52 -0700

How about oauth_callback?

Marius

On Thu, Apr 15, 2010 at 2:41 PM, Luke Shepard <[email-masked]> 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.
>
>
>
>
>
> 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
>
>
> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Apr 2010 12:10:04 -0400

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.
>
> different in the user-agent flow (redirector) when it’s essentially  
> doing the same thing.
>
>
> 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
>
>
> "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

---

From: Luke Shepard <[email-masked]>
Date: Fri, 16 Apr 2010 09:50:59 -0700

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:[email-masked]] 
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

--Richard

On Apr 15, 2010, at 5:41 PM, Luke Shepard wrote:

> The protected resource typically accepts "callback" as a parameter  
> 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  
> 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.
>
>
> I don't think it is that confusing. Its a completely different

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 16 Apr 2010 12:05:43 -0700

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 <[email-masked]> wrote:

> Facebook API requests are protected resources. They can be called either in
> a browser or in a server-to-server environment.
>
> The output (you can play with it here:
> http://fbrell.com/fb.api/everyone-data ):
>
> The "callback" parameter is used pretty universally for JSONP requests. For
> instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Apr 2010 15:26:57 -0400

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?
>
> Facebook API requests are protected resources. They can be called  
> either in a browser or in a server-to-server environment.
>
> The "callback" parameter is used pretty universally for JSONP  
> requests. For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/
>

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 16 Apr 2010 12:31:22 -0700

On Fri, Apr 16, 2010 at 12:26 PM, Richard Barnes <[email-masked]> wrote:

> 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.

> something unlikely to collide, e.g., "oauth_*".  (Note: This applies to all
> OAuth parameters, not just "callback").
>

(this discussion is going on in a separate thread)

> shouldn't be passed as application-layer things (request parameters), but
> rather as HTTP-layer things, e.g., in an Authorization header?
>

These all have to work as a browser GET request

>  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,
>> Facebook API requests are protected resources. They can be called either
>> in a browser or in a server-to-server environment.
>>
>> The "callback" parameter is used pretty universally for JSONP requests.
>> For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/
>>

---

From: Luke Shepard <[email-masked]>
Date: Fri, 16 Apr 2010 12:35:02 -0700

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:[email-masked]] 
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

--Richard

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 16 Apr 2010 12:42:04 -0700

On Fri, Apr 16, 2010 at 12:35 PM, Luke Shepard <[email-masked]>wrote:

> 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".
>

Callback URIs may have their own parameters (not in the live spec yet, but
think we agreed to on a separate thread)

>
> The issue is softer - in this case, we are anticipating and preventing what
> would otherwise be a common source of developer confusion.
>

I'm fine with either.

---

From: Naitik Shah <[email-masked]>
Date: Fri, 16 Apr 2010 12:11:33 -0700

+1 for redirect_uri -- highest semantic value imho.

-Naitik

On Apr 16, 2010, at 12: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?
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 13:45:34 -0700

We should use the right term, not just the less conflicting term.

The Web Callback flow uses a callback from the server to the client - this is not a redirection. The User-Agent flow uses a redirection which is fundamentally different from a callback.

If you don't want to use callback and want to use the same name for both, it needs to be something more generic like client_uri.

EHL

On 4/16/10 12:11 PM, "Naitik Shah" <[email-masked]> wrote:

-Naitik

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 16 Apr 2010 13:57:08 -0700

On Fri, Apr 16, 2010 at 1:45 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> The Web Callback flow uses a callback from the server to the client – this
> is not a redirection. The User-Agent flow uses a redirection which is
> fundamentally different from a callback.
>

   callback
         An absolute URI to which the authorization server will redirect
         the end user back when the end user authorization step is
         completed.  The authorization server MAY require the client to
         pre-register their callback URI.

   redirection
         An absolute URI to which the authorization server will redirect
         the user-agent to when the end user authorization step is
         completed.  The authorization server SHOULD require the client
         to pre-register their redirection URI.

These look the same to me, and "redirect_uri/url" works. Open to other
terms.

> If you don’t want to use callback and want to use the same name for both,
> it needs to be something more generic like client_uri.
>
> EHL
>
>
> > From: Richard Barnes [mailto:[email-masked] <[email-masked]>]
> > > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On
> > > Behalf Of Eran Hammer-Lahav

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 14:11:48 -0700

I'll just go with redirect_uri.

EHL

On 4/16/10 1:57 PM, "Evan Gilbert" <[email-masked]> wrote:

On Fri, Apr 16, 2010 at 1:45 PM, Eran Hammer-Lahav <[email-masked]> wrote:
We should use the right term, not just the less conflicting term.

   callback

   redirection

These look the same to me, and "redirect_uri/url" works. Open to other terms.

EHL

On 4/16/10 12:11 PM, "Naitik Shah" <[email-masked] <http://[email-masked]> > wrote:

-Naitik

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

> On Fri, Apr 16, 2010 at 9:50 AM, Luke Shepard <[email-masked] <http://[email-masked]> > wrote:
> > From: [email-masked] <http://[email-masked]>  [mailto:[email-masked]] On
> > On 4/10/10 12:35 PM, "Naitik Shah" <[email-masked] <http://[email-masked]> > wrote:
> >
> > [email-masked] <http://[email-masked]>
> > [email-masked] <http://[email-masked]>
> [email-masked] <http://[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked] <http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth