No subject

Wed Mar 4 18:19:19 UTC 2009

> 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 c=
lue- like what if the RP could say "don't send POST requests back, just sen=
d no more than X chars in the GET no matter what". Then the OP could just d=
rop data if it went over the limit ... or something.

On 3/25/09 9:26 PM, "James Henstridge" <james at jamesh.id.au> wrote:

On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins <mart at degeneration.co.uk> wr=
ote:
> James Henstridge wrote:
>>
>> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <lshepard at facebook.com>
>> wrote:
>>>
>>> One crude way to do it would be to have the caller specify that they wa=
nt
>>> the return_to args simply appended instead of integrated into the URL-
>>> perhaps an argument like openid.append_return_to_params=3Dtrue. But tha=
t
>>> 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 i=
t
> 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 complet=
ely
> 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 at openid.net
http://openid.net/mailman/listinfo/specs

--_000_C5F1A83B28A6Dlshepardfacebookcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Defining how OpenID should behave with fragments in the return_t=
o url</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>This thread has been really useful &#8211; thanks for the responses e=
veryone. I have a few inline responses to a few different emails, bear with=
 me while I try to unify the thread. <BR>
<BR>