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

[Evan Gilbert <[e-mail]>]

On Fri, Apr 16, 2010 at 12:35 PM, Luke Shepard <[e-mail]>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.
>
> redirect_url (or redirect_uri, but we use _url elsewhere so whatever) seems
> the best to me too.
>

I'm fine with either.


>
> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> 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
> > <[e-mail]> 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:[e-mail]]
> > 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: [e-mail] [mailto:[e-mail]] 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" <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>