Re: Defining how OpenID should behave with fragments in the return_to url
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 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). Yup, great point. We can just say that it is valid (as Google and Yahoo have implemented it today) thus blessing this as a potential optimization going forward. From Allen: 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. After thinking a bit more on this, I realized that while performance of the checkid_setup call in the popup is important, it’s a one-time cost so not that big of a deal. A much bigger issue is the performance of checkid_immediate in an iframe. For Connect, we do the equivalent of that on every single page. For OpenID, I can see a case where a relying party would run a checkid_immediate on every page (to make sure the user was still logged in). In fact, a relying party might want to check multiple OpenID providers on a page load – maybe even dozens or hundreds, potentially. If they did that, then the performance of each call would definitely be a much bigger issue, and this HTTP load would become more important. From James: Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. The POST response is a good point and clearly a valid use case, and I think it’s supported no matter what we decide to do. It’s possible to build a receiver that handles POST params if they are present, but otherwise serves up the correct cache headers and Javascript to handle the GET. That would provide a performance boost in the common case, while still being fully compatible with the spec. For what it's worth, we went through a similar discussion when we were trying to define a version of OAuth for unregistered consumers, and are proposing the following there ( http://step2.googlecode.com/svn/spec/unregistered_oauth/latest/oauth-unregistered.html ): - use POST by default, to reduce the risk posed by open redirectors (which tend to not redirect on a POST) - when using GET (which can be requested by the consumer), put the sensitive payload into the fragment. This has the performance benefit Luke mentions if the consumer is Javascript, _plus_ also helps with open redirectors - the sensitive payload doesn't hit the servers and most browsers drop it across 302s. Dirk. From Martin: To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Maybe having the fragment is a clue, but I’d prefer an even more explicit clue- like what if the RP could say “don’t send POST requests back, just send no more than X chars in the GET no matter what”. Then the OP could just drop data if it went over the limit ... or something. On 3/25/09 9:26 PM, James Henstridge ja...@jamesh.id.au wrote: 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 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. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the
Re: Defining how OpenID should behave with fragments in the return_to url
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: http://example.com/callback?foo=bar#fragmentoauth_token=token New Behavior: http://example.com/callback?foo=baroauth_token=token#fragment 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) For the time being, we'll just keep the current behavior on the Yahoo OP. 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. Allen 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 a...@yahoo-inc.com mailto: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?queryopenid.ns=#hash http://open.lukeshepard.com/openid_receiver.html?queryopenid.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
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 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). Yup, great point. We can just say that it is valid (as Google and Yahoo have implemented it today) thus blessing this as a potential optimization going forward. From Allen: 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. After thinking a bit more on this, I realized that while performance of the checkid_setup call in the popup is important, it's a one-time cost so not that big of a deal. A much bigger issue is the performance of checkid_immediate in an iframe. For Connect, we do the equivalent of that on every single page. For OpenID, I can see a case where a relying party would run a checkid_immediate on every page (to make sure the user was still logged in). In fact, a relying party might want to check multiple OpenID providers on a page load - maybe even dozens or hundreds, potentially. If they did that, then the performance of each call would definitely be a much bigger issue, and this HTTP load would become more important. From James: Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. The POST response is a good point and clearly a valid use case, and I think it's supported no matter what we decide to do. It's possible to build a receiver that handles POST params if they are present, but otherwise serves up the correct cache headers and Javascript to handle the GET. That would provide a performance boost in the common case, while still being fully compatible with the spec. From Martin: To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Maybe having the fragment is a clue, but I'd prefer an even more explicit clue- like what if the RP could say don't send POST requests back, just send no more than X chars in the GET no matter what. Then the OP could just drop data if it went over the limit ... or something. On 3/25/09 9:26 PM, James Henstridge ja...@jamesh.id.au wrote: 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 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. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the standards), but I suppose it'd still be a win if the POST requests are infrequent. This is starting to become a lot more complicated than the simple static return_to page from the initial proposal though. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. It might be worth going back to basics and considering whether there are other solutions. The stated aim was to provide the best user experience
Re: Defining how OpenID should behave with fragments in the return_to url
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 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). Yup, great point. We can just say that it is valid (as Google and Yahoo have implemented it today) thus blessing this as a potential optimization going forward. From Allen: 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. After thinking a bit more on this, I realized that while performance of the checkid_setup call in the popup is important, it’s a one-time cost so not that big of a deal. A much bigger issue is the performance of checkid_immediate in an iframe. For Connect, we do the equivalent of that on every single page. For OpenID, I can see a case where a relying party would run a checkid_immediate on every page (to make sure the user was still logged in). In fact, a relying party might want to check multiple OpenID providers on a page load – maybe even dozens or hundreds, potentially. If they did that, then the performance of each call would definitely be a much bigger issue, and this HTTP load would become more important. From James: Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. The POST response is a good point and clearly a valid use case, and I think it’s supported no matter what we decide to do. It’s possible to build a receiver that handles POST params if they are present, but otherwise serves up the correct cache headers and Javascript to handle the GET. That would provide a performance boost in the common case, while still being fully compatible with the spec. I would add that, in the case of checkid_immediate, it is not advisable to have many extensions. Each request to release an attribute increases the odds that the user will need to be prompted to approve the request, and therefore decreases the chance of success of a checkid_immediate request. As Luke pointed out, checkid_immediate stands to gain most from the latency improvements. From Martin: To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Maybe having the fragment is a clue, but I’d prefer an even more explicit clue- like what if the RP could say “don’t send POST requests back, just send no more than X chars in the GET no matter what”. Then the OP could just drop data if it went over the limit ... or something. On 3/25/09 9:26 PM, James Henstridge ja...@jamesh.id.au wrote: 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 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. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the standards), but I suppose it'd still be a win if the POST requests are infrequent. This is starting to become a lot more complicated than the simple static return_to page from the initial proposal though. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the
Re: Defining how OpenID should behave with fragments in the return_to url
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 sounds hackish and I’d love to hear feedback on a better way to do this. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. If it helps, you could reproduce such a response with a form like: form action=http://open.lukeshepard.com/openid_receiver.html?query#hash; method=post accept-charset=UTF-8 input type=hidden name=openid.ns value=... ... input type=submit value=Submit /form This proposal sounds like something that will work most of the time but fail in a number of valid cases. It'd be nice to support the popup based authentication workflow well, but I am not convinced that relying on this quirk is the right way to do so. James. ___ 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
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 openid.append_return_to_params=true. But that sounds hackish and I’d love to hear feedback on a better way to do this. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. ___ 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
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 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. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the standards), but I suppose it'd still be a win if the POST requests are infrequent. This is starting to become a lot more complicated than the simple static return_to page from the initial proposal though. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. It might be worth going back to basics and considering whether there are other solutions. The stated aim was to provide the best user experience possible for running an OpenID authentication request through a pop up window and then communicating the results back to the main window. Luke's proposal is one possible solution, but I wouldn't want to impose limitations on the specification if there is an alternative that also solves the problem. James. ___ 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
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?queryopenid.ns=#hash http://open.lukeshepard.com/openid_receiver.html?queryopenid.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
Re: Defining how OpenID should behave with fragments in the return_to url
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?queryopenid.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
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? 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?queryopenid.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
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?queryopenid.ns=#hash 2. http://open.domain.com/openid_receiver.html?query#hashopenid.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 br...@google.com 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 balf...@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 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?queryopenid.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
Re: Defining how OpenID should behave with fragments in the return_to url
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 lshep...@facebook.com 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 br...@google.com 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 balf...@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 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:
Re: Defining how OpenID should behave with fragments in the return_to url
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?queryopenid.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
