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<B=
R>
> 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 here to=
o.<BR>
<BR>
Maybe having the fragment is a clue, but I’d prefer an even more expl=
icit clue- like what if the RP could say “don’t send POST reque=
sts 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=
.<BR>
<BR>
<BR>
On 3/25/09 9:26 PM, "James Henstridge" <<a href=3D"james at james=
h.id.au">james at jamesh.id.au</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>On Thu, Mar 26, 2009 at 1:49 AM, Martin Atk=
ins <<a href=3D"mart at degeneration.co.uk">mart at degeneration.co.uk</a>>=
wrote:<BR>
> James Henstridge wrote:<BR>
>><BR>
>> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <<a href=3D"lshep=
ard at facebook.com">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’d 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, bu=
t 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 worked<B=
R>
> 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). While this might be acceptable<=
BR>
for Luke's particular use case, it might leave it unsolved for others.<BR>
It 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"specs at openid.net">specs at openid.net</a><BR>
<a href=3D"http://openid.net/mailman/listinfo/specs">http://openid.net/mail=
man/listinfo/specs</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>
--_000_C5F1A83B28A6Dlshepardfacebookcom_--
More information about the specs
mailing list