No subject
Wed Mar 4 18:19:19 UTC 2009
> To be honest, I'd be surprised if POST requests from OP to RP work=
ed<br>
> interoperably today, but the trick of using the # on the end of the<br=
>
> return_to URL to signal to a supporting OP "I'm trying to do =
this<br>
> completely client-side, so don't do a POST request" works her=
e too.<br>
<br></div>
Maybe having the fragment is a clue, but I=92d prefer an even more explicit=
clue- like what if the RP could say =93don=92t send POST requests back, ju=
st send no more than X chars in the GET no matter what=94. Then the OP coul=
d just drop data if it went over the limit ... or something.<div>
<div></div><div class=3D"h5"><br>
<br>
<br>
On 3/25/09 9:26 PM, "James Henstridge" <<a href=3D"http://jame=
s at jamesh.id.au" target=3D"_blank">james at jamesh.id.au</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div class=3D"h5"><blockquote><fo=
nt face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size: 11=
pt;">On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins <<a href=3D"http://m=
art at degeneration.co.uk" target=3D"_blank">mart at degeneration.co.uk</a>> w=
rote:<br>
> James Henstridge wrote:<br>
>><br>
>> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <<a href=3D"http:=
//lshepard at facebook.com" target=3D"_blank">lshepard at facebook.com</a>><br=
>
>> wrote:<br>
>>><br>
>>> One crude way to do it would be to have the caller specify tha=
t they want<br>
>>> the return_to args simply appended instead of integrated into =
the URL-<br>
>>> perhaps an argument like openid.append_return_to_params=3Dtrue=
. But that<br>
>>> sounds hackish and I=92d love to hear feedback on a better way=
to do this.<br>
>><br>
>> How would this interact with OpenID providers that respond via a P=
OST<br>
>> request instead of a GET? =A0This is something they are permitted =
to do<br>
>> according to the spec, and may decide to do so even if the<br>
>> authentication request was started with a GET if the response is l=
arge<br>
>> enough.<br>
>><br>
><br>
> This is a good point, but it seems like again it can be worked around =
by<br>
> making openid_reciever.html accept POST requests.<br>
><br>
> Unlike the query string, this can't be done completely client side=
, but it<br>
> ought to be reasonably simple to set up some kind of rewriterule or ot=
her<br>
> indirection trick to make POST requests to openid_reciever.html actual=
ly get<br>
> served by a non-static endpoint.<br>
<br>
Any intermediate caches would also drop their cached versions when<br>
they see a POST request too (assuming they follow the standards), but<br>
I suppose it'd still be a win if the POST requests are infrequent.<br>
<br>
This is starting to become a lot more complicated than the "simple<br>
static return_to page" from the initial proposal though.<br>
<br>
<br>
> To be honest, I'd be surprised if POST requests from OP to RP work=
ed<br>
> interoperably today, but the trick of using the # on the end of the<br=
>
> return_to URL to signal to a supporting OP "I'm trying to do =
this completely<br>
> client-side, so don't do a POST request" works here too.<br>
<br>
Disallowing post responses limits the use of the more verbose<br>
extensions (e.g. attribute exchange). =A0While this might be acceptable<br>
for Luke's particular use case, it might leave it unsolved for others.<=
br>
=A0It might be worth going back to basics and considering whether there<br>
are other solutions.<br>
<br>
The stated aim was to provide the best user experience possible for<br>
running an OpenID authentication request through a pop up window and<br>
then communicating the results back to the main window.<br>
<br>
Luke's proposal is one possible solution, but I wouldn't want to<br=
>
impose limitations on the specification if there is an alternative<br>
that also solves the problem.<br>
<br>
James.<br>
_______________________________________________<br>
specs mailing list<br>
<a href=3D"http://specs@openid.net" target=3D"_blank">specs at openid.net</a><=
br>
<a href=3D"http://openid.net/mailman/listinfo/specs" target=3D"_blank">http=
://openid.net/mailman/listinfo/specs</a><br>
<br>
</span></font></blockquote>
</div></div></div>
<br>_______________________________________________<br>
specs mailing list<br>
<a href=3D"mailto:specs at openid.net">specs at openid.net</a><br>
<a href=3D"http://openid.net/mailman/listinfo/specs" target=3D"_blank">http=
://openid.net/mailman/listinfo/specs</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br>--Breno<br><br>+1 (=
650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A=
<br>PST (GMT-8) / PDT(GMT-7)<br>
--0016364178fd964f26046612bd0b--
More information about the specs
mailing list