<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Oops, I missed the followups to this thread. We updated our OAuth
service this week to change the behavior for fragments in the
oauth_callback URL so that we always return query parameters *before*
the fragment. <br>
<br>
oauth_callback=<a class="moz-txt-link-freetext" href="http://example.com/callback?foo=bar#fragment">http://example.com/callback?foo=bar#fragment</a><br>
<br>
Old Behavior:<br>
<a class="moz-txt-link-freetext" href="http://example.com/callback?foo=bar#fragment&oauth_token=token">http://example.com/callback?foo=bar#fragment&oauth_token=token</a><br>
<br>
New Behavior:<br>
<a class="moz-txt-link-freetext" href="http://example.com/callback?foo=bar&oauth_token=token#fragment">http://example.com/callback?foo=bar&oauth_token=token#fragment</a><br>
<br>
It sounds like the Old Behavior is what Luke is asking for. It works
well if the parameters are parsed in JS, without any server side help,
but appending parameters after the fragment prevents the params from
being sent to the server (which is the point, if you're trying to avoid
caching, but is broken if you actually want the process the params on
the server)<br>
<br>
For the time being, we'll just keep the current behavior on the Yahoo
OP.<br>
<br>
Given that this fragment technique is intended to improve the user
experience, especially in the context of a popup window, I think that
we may be able to document the correct behavior this in the forthcoming
UI Extension.<br>
<br>
Allen<br>
<br>
<br>
<br>
<br>
Dirk Balfanz wrote:
<blockquote
cite="mid:60c552b80903241512gf389b19ve74e1f3655b2466e@mail.gmail.com"
type="cite">Wait - isn't Luke saying that Yahoo! is currently
supporting this just fine? What are you "fixing"?
<div><br>
</div>
<div>Dirk.<br>
<br>
<div class="gmail_quote">On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Hi Luke,<br>
<br>
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.<br>
<br>
We will update our OP to support return_to URLs with a fragment. I'll
let you know when it's fixed.<br>
<br>
Thanks<br>
Allen<br>
<br>
<br>
<br>
Luke Shepard wrote:
<blockquote type="cite">
<div>
<div class="h5"> <font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi-<br>
<br>
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.<br>
<br>
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.<br>
<br>
Here’s a description of a technique:<br>
<a moz-do-not-send="true"
href="http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/"
target="_blank">http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/</a><br>
<br>
A simple way to do this is to have a simple receiver. The response will
append query parameters:<br>
<br>
<a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.php?openid.ns=....."
target="_blank">http://open.lukeshepard.com/openid_receiver.php?openid.ns=.....</a>.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.html#openid.ns=....."
target="_blank">http://open.lukeshepard.com/openid_receiver.html#openid.ns=.....</a>.<br>
<br>
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.<br>
<br>
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.<br>
<br>
When given a return_to of <a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.html?query#hash"
target="_blank">http://open.lukeshepard.com/openid_receiver.html?query#hash</a><br>
<br>
Google: <a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=..."
target="_blank">http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=...</a>.<br>
Yahoo: <a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=..."
target="_blank">http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=...</a>.<br>
MySpaceID: <a moz-do-not-send="true"
href="http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=....#hash"
target="_blank">http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=....#hash</a><br>
MyOpenID: fails outright - “invalid return_to”<br>
<br>
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.<br>
<br>
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.<br>
<br>
Also, let me know if this is the wrong list or whatever.<br>
<br>
thanks,<br>
- Luke<br>
</span></font> </div>
</div>
<pre><hr size="4" width="90%">
_______________________________________________
specs mailing list
<a moz-do-not-send="true" href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
specs mailing list<br>
<a moz-do-not-send="true" href="mailto:specs@openid.net">specs@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>