Re: Defining how OpenID should behave with fragments in the return_to url

[Martin Atkins]

This looks similar in principle to the "AJAX"-ish (though not really 
AJAX at all) mode of OpenID that was in the early demos but no-one 
actually seems to have implemented in practice. The trick there was to 
do the OP dance in a hidden iframe and have the return_to page 
communicate with the outer page in much the same way as the popup does.


However, the optimization of doing it with the fragment identifier is 
interesting.


My first concern was backward compatibility, but it actually looks like 
we get back-compat by accident as long as openid_reciever.html is able 
to actually process the query string if it's present.


Here's a strawman:

* If the return_to URL ends with a # character, a supporting OP (or an 
OP that's doing this by accident) should make the return_to URL by 
appending the ? after the # and then adding the query string arguments 
as normal.


* The non-fragment part of the URL MUST support having the arguments 
passed in the *real* query string. In this case, the fragment part 
should be ignored and is likely to be the empty string anyway.


This allows OPs that don't work in the way you suggest to still work, 
albeit with worse UI performance due to the extra round-trip that will 
inevitably be generated.


As far as I can tell, your openid_reciever.html can still be a static 
file in the query string case, becausee most existing web servers will 
accept and silently drop query string arguments on URLs that address 
static files, and the full URL should be available client side in 
docment.location to allow you to retrieve the query string.


It'd be good to see how more existing OPs behave when presented with a 
return_to URL that ends with a #. Having MyOpenID fail is a show-stopper 
for the above approach IMHO, but hopefully they will "fix" their 
implementation if they are the only one broken.


(I've quite deliberately said *ends with* rather than *contains* a # 
here, because that's a simpler thing to catch for folks who will need to 
fight their local URI-mangling library in order to implement this, which 
I assume applies to MySpace -- I presume that their correct behavior 
came "for free" with the .NET System.Net.Uri class.)



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

Re: Defining how OpenID should behave with fragments in the return_to url

[Breno de Medeiros]

On Tue, Mar 24, 2009 at 7:09 PM, Andrew Arnott wrote:

> Sorry, but I sorely disagree with option #2.  Perf improvement or no.  As a
> perf engineer at Microsoft says, "I can optimize performance down to 0 ms if
> I am willing to accept incorrect behavior."
> The URI must not contain a hash in the middle of the query string unless
> that hash is URI escaped, which of course would defeat the perf gain you're
> reaching for.  Therefore I urge OpenID 2.1 to mandate option #1, which I
> wouldn't call currently ambiguous since the URI spec is assumed to be
> followed and that would mandate it, removing the ambiguity.
>

Yes, however, the fragment part of an URI may contain '?' and '&' unencoded.
So the return_to URIs returned by the Google and Yahoo! ops are valid URIs,
without any query parameters, which is why the optimization works to start
with.

The very legitimate question here is whether it is acceptable for the OpenID
spec to define that the query can be encoded in the fragment if a fragment
is present in the return_to URL. If the spec were to say it is valid, then
there is no incorrect behavior (as no other spec is otherwise violated).



>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>
>
> On Tue, Mar 24, 2009 at 4:42 PM, Luke Shepard wrote:
>
>>  Ha – thanks Breno :) I’m basically saying that the spec is ambiguous,
>> which is proven by the fact that multiple major providers have different
>> interpretations of how to handle this case.
>>
>> When given a return_to url of
>> http://open.domain.com/openid_receiver.html?query#hash, there are two
>> options for how to return the response:
>>
>> 1. http://open.domain.com/openid_receiver.html?query*&openid.ns=*
>> #hash
>> 2. http://open.domain.com/openid_receiver.html?query#hash*&openid.ns=
>> *
>> Section 4.1.2 of the spec says:
>>  “When a message is sent to an HTTP server, it MUST be encoded using a
>> form encoding specified in Section 17.13.4 of [HTML401] (W3C, “HTML 4.01
>> Specification,” .).”
>>
>> According to the URI spec, the fragment portion is explicitly undefined,
>> so the “right” way to do this is Option #1, which is to include it in the
>> query string
>>
>> Option #2 is therefore technically wrong. However, it has the nice side
>> effect of allowing this performance optimization. So we should have a way
>> for the RP to specify that they want the return in the fragment, not the
>> query, for performance reasons.
>>
>> I don’t think this is something super urgent, but it should be clarified
>> in the next version of the spec. We can probably work it out next time we’re
>> in person.
>>
>>
>>
>> On 3/24/09 4:28 PM, "Breno de Medeiros"  wrote:
>>
>> 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  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  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 ser

Re: Defining how OpenID should behave with fragments in the return_to url

[Andrew Arnott]

Sorry, but I sorely disagree with option #2.  Perf improvement or no.  As a
perf engineer at Microsoft says, "I can optimize performance down to 0 ms if
I am willing to accept incorrect behavior."
The URI must not contain a hash in the middle of the query string unless
that hash is URI escaped, which of course would defeat the perf gain you're
reaching for.  Therefore I urge OpenID 2.1 to mandate option #1, which I
wouldn't call currently ambiguous since the URI spec is assumed to be
followed and that would mandate it, removing the ambiguity.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Tue, Mar 24, 2009 at 4:42 PM, Luke Shepard  wrote:

>  Ha – thanks Breno :) I’m basically saying that the spec is ambiguous,
> which is proven by the fact that multiple major providers have different
> interpretations of how to handle this case.
>
> When given a return_to url of
> http://open.domain.com/openid_receiver.html?query#hash, there are two
> options for how to return the response:
>
> 1. http://open.domain.com/openid_receiver.html?query*&openid.ns=*#hash
> 2. http://open.domain.com/openid_receiver.html?query#hash*&openid.ns=
> *
> Section 4.1.2 of the spec says:
>  “When a message is sent to an HTTP server, it MUST be encoded using a form
> encoding specified in Section 17.13.4 of [HTML401] (W3C, “HTML 4.01
> Specification,” .).”
>
> According to the URI spec, the fragment portion is explicitly undefined, so
> the “right” way to do this is Option #1, which is to include it in the query
> string
>
> Option #2 is therefore technically wrong. However, it has the nice side
> effect of allowing this performance optimization. So we should have a way
> for the RP to specify that they want the return in the fragment, not the
> query, for performance reasons.
>
> I don’t think this is something super urgent, but it should be clarified in
> the next version of the spec. We can probably work it out next time we’re in
> person.
>
>
>
> On 3/24/09 4:28 PM, "Breno de Medeiros"  wrote:
>
> 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  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  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?

Re: Defining how OpenID should behave with fragments in the return_to url

[Luke Shepard]

Ha - thanks Breno :) I'm basically saying that the spec is ambiguous, which is 
proven by the fact that multiple major providers have different interpretations 
of how to handle this case.

When given a return_to url of 
http://open.domain.com/openid_receiver.html?query#hash, there are two options 
for how to return the response:

1. http://open.domain.com/openid_receiver.html?query&openid.ns=#hash
2. http://open.domain.com/openid_receiver.html?query#hash&openid.ns=

Section 4.1.2 of the spec says:
 "When a message is sent to an HTTP server, it MUST be encoded using a form 
encoding specified in Section 17.13.4 of [HTML401] (W3C, "HTML 4.01 
Specification," .)."

According to the URI spec, the fragment portion is explicitly undefined, so the 
"right" way to do this is Option #1, which is to include it in the query string

Option #2 is therefore technically wrong. However, it has the nice side effect 
of allowing this performance optimization. So we should have a way for the RP 
to specify that they want the return in the fragment, not the query, for 
performance reasons.

I don't think this is something super urgent, but it should be clarified in the 
next version of the spec. We can probably work it out next time we're in person.


On 3/24/09 4:28 PM, "Breno de Medeiros"  wrote:

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

Re: 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  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  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
>
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Defining how OpenID should behave with fragments in the return_to url

[Dirk Balfanz]

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

Re: Defining how OpenID should behave with fragments in the return_to url

[Allen Tom]

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 list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Defining how OpenID should behave with fragments in the return_to url

[Luke Shepard]

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 list
specs@openid.net
http://openid.net/mailman/listinfo/specs