Responses below. On Jul 6, 2010, at 2:23 PM, Brian Eaton wrote:
> On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard <lshep...@facebook.com> wrote: >> Two points: >> >> 1/ I agree that it can be onerous for clients to host web pages. It's not a >> matter of expense but of complexity. >> >> BUT >> >> 2/ As we discussed previously in our in-person meeting, this should be >> handled by a different endpoint, and not be the responsibility for the >> provider. If Google wishes to support this for their desktop apps, then it >> should provide an endpoint that handles the OAuth response and puts it in >> the <title>. I can say that Facebook has no interest in supporting this hack >> on the server side, but clients that want it can use their own html file >> that does it for them. >> >> For example, for Javascript web apps it is a pain to host a cross-domain >> receiver file. So we host one on behalf of developers (called xd_proxy.php). >> But it is not part of our server-side logic. >> >> If you want to write a spec for that, then great, but the <title> hack does >> not belong in the main spec. > > Luke - > > A couple of questions for you. > > Question #1: In another thread, you mentioned "We require either > pre-registration of the callback URL, or that the app uses a standard > redirect URL on Facebook.com (which could only be used by a desktop > app)." > > It sounds like both Google and Facebook have needed to provide a > standard way for desktop applications to receive callback URLs, and > that we've both opted to do so by hosting a page on our own site. > > What approach does your callback URL use for passing the authorization > code down to the desktop app? We suggest developers use the user-agent flow, and retrieve the access token after the fragment in the URL. We include links for .NET, Adobe Air, and Objective C libraries. We haven't really run into issues with desktop apps for which this is not possible (to my knowledge). http://developers.facebook.com/docs/authentication/desktop > And do you see value in standardizing that approach? You mentioned that there were desktop apps that aren't able to read the URL values, but which can read the <title> value of apps - I know both Yahoo and Google mentioned this. If you can show that this type of app is a common scenario, then I can see some value in making it widespread. For now I haven't really seen a lot of examples of this in the wild such that it's worth standardizing. One way to standardize this would be to host a file on a common domain - initially probably something like google.com, and then later perhaps a file on oauth.org or somewhere. It could use Javascript or server-side logic to intercept the access token and display it in the <title>. Providers would need to accept redirect_uri values that contain that well known URL. But it is much easier for a provider to just say "Oh, you're using oauth.org/desktoptitleauth.html? okay" than it is to implement the desktop title trick themselves. > (We settled on the <title> hack because it was very portable. But > it's pretty ugly, and we'd love something better.) > > > Question #2: most of the installed app developers we talk to ask how > they can provide some sort of display name for their application, both > on the approval page and on the revocation page. Do you see the same > requirement, and if so how do you meet it? We don't allow unregistered applications. When an app registers their client_id, they can specify a name and multiple sizes of icons. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
