On Thu, Mar 26, 2009 at 9:46 PM, Luke Shepard lshep...@facebook.com wrote:
This thread has been really useful – thanks for the responses everyone. I
have a few inline responses to a few different emails, bear with me while I
try to unify the thread.
From Breno:
The very legitimate
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.
oauth_callback=http://example.com/callback?foo=bar#fragment
Old Behavior:
This thread has been really useful - thanks for the responses everyone. I have
a few inline responses to a few different emails, bear with me while I try to
unify the thread.
From Breno:
The very legitimate question here is whether it is acceptable for the OpenID
spec to define that the
On Thu, Mar 26, 2009 at 9:46 PM, Luke Shepard lshep...@facebook.com wrote:
This thread has been really useful – thanks for the responses everyone. I
have a few inline responses to a few different emails, bear with me while I
try to unify the thread.
From Breno:
The very legitimate
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:
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
James Henstridge wrote:
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:
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
On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote:
James Henstridge wrote:
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com
wrote:
One crude way to do it would be to have the caller specify that they want
the return_to args simply appended
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
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
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 balf...@google.com wrote:
Wait - isn't Luke saying that Yahoo! is currently supporting this just
fine?
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
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,
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
13 matches
Mail list logo
