Wait - isn't Luke saying that Yahoo! is currently supporting this just fine? What are you "fixing"? Dirk.
On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom <a...@yahoo-inc.com> wrote: > Hi Luke, > > I have to confess that I was not aware of technique of passing parameters > after the fragment to take advantage of browser caching, until you blogged > about it. Since then, we've noticed that developers have been doing this, > and in fact, we fixed the same bug on our OAuth service just last week. > > We will update our OP to support return_to URLs with a fragment. I'll let > you know when it's fixed. > > Thanks > Allen > > > > Luke Shepard wrote: > > Hi- > > I’ve noticed an ambiguity with the way URLs are handled that exists in the > current spec. I’m hoping we can resolve it for OpenID 2.1. > > When we move the OpenID transaction into a popup window, we need a way for > the popup to communicate back with the parent. The way to do this is to set > a return_to URL that, when loaded, reads the parameters and communicates > with the parent window somehow. > > Here’s a description of a technique: > > http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/ > > A simple way to do this is to have a simple receiver. The response will > append query parameters: > > http://open.lukeshepard.com/openid_receiver.php?openid.ns=...... > > However, there is a small performance problem with this approach. The user > will see a blank-looking popup for a moment while the server processes the > OpenID arguments. An optimization is to put up a simple, cacheable static > HTML file that chucks the OpenID params back to the parent frame. The parent > can then provide some visual feedback to the user while it sends the OpenID > parameters off for processing. This results in a snappier experience. > > If the static HTML file has no parameters and sends out long-lived cache > headers, then the response won’t even trigger a server load, and the whole > process can appear faster to the user. In this case, the response would look > like this: > > http://open.lukeshepard.com/openid_receiver.html#openid.ns=...... > > Note that the hash appears instead of a question-mark. That tells the > browser that it doesn’t need to load an extra file, and it can save perhaps > a quarter or half second of latency for the user on average. > > Okay, so the point is that different OpenID providers currently interpret > the hash differently. I think we should explicitly define a behavior that > makes sense and accomodates the above suggestion. Here’s how they currently > behave. > > When given a return_to of > http://open.lukeshepard.com/openid_receiver.html?query#hash > > Google: > http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=.... > Yahoo: > http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=.... > MySpaceID: > http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=....#hash > MyOpenID: fails outright - “invalid return_to” > > By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. > But the “correct” way doesn’t allow the performance optimization listed > above. I’d like to see a way to accommodate the hash url. > > One crude way to do it would be to have the caller specify that they want > the return_to args simply appended instead of integrated into the URL- > perhaps an argument like openid.append_return_to_params=true. But that > sounds hackish and I’d love to hear feedback on a better way to do this. > > Also, let me know if this is the wrong list or whatever. > > thanks, > - Luke > > ------------------------------ > > _______________________________________________ > specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
