Defining how OpenID should behave with fragments in the return_to url

[Breno de Medeiros]

I must confess that Google's support is also accidental :)

Thanks for pointing it out to us, though, we will keep in mind not to ever
"fix" it.

On Tue, Mar 24, 2009 at 3:12 PM, Dirk Balfanz <balfanz at google.com> wrote:

> 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 <atom at 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 listspecs at openid.nethttp://openid.net/mailman/listinfo/specs
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090324/3f874ead/attachment-0002.htm>