Ah, I see. You don't store the return_to URL that you're expecting in session state -- you regenerate it at the next request and verify that they match. <br><br>I agree that the OP shouldn't <i>change</i> a return_to URL, but the return_to URL can't be guaranteed in the case of an unsolicited assertion as allowed by OpenID 2.0, since the return_to was never sent from the RP to the OP. It makes me wonder how the Janrain libraries receive unsolicited assertions and process them. I haven't tested it myself. Do you know?<br>
<br>Just my own opinion, but it seems that verifying the return_to in this manner is beyond the spec, as the spec only demands that return_to and the actual request URL match in their particular way... not that the OP didn't tamper with it in the meantime. Again, I agree that OPs <i>shouldn't</i>, but the spec doesn't disallow it, so adding this verification to the Janrain libraries seems like it just potentially breaks things rather than add any useful function. Again, just my 2 cents.<br clear="all">
<br>Andrew Arnott
<br><br><div class="gmail_quote">On Wed, Jun 11, 2008 at 12:32 PM, Josh Hoyt <<a href="mailto:josh@janrain.com">josh@janrain.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/6/11 Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>>:<br>
<div class="Ih2E3d">> Is this new with the latest versions then? As I recall, there was a ticket<br>
> for one of the libraries just closed that discussed how return_to in the<br>
> query and the actual request itself did match, but they weren't the original<br>
> return_to passed to the OP, so the library rejected it. I think it was the<br>
> Ruby one that did it (the others didn't, apparently).<br>
<br>
</div>IIRC, the problem was that the provider altered the return_to URL. The<br>
alteration did not change the meaning of the URL, but the library was<br>
expecting the URL to have passed through unchanged (since the code<br>
that generates the return_to URL and that validates it are the same.)<br>
I consider it kind of pathological for the provider to alter the<br>
return_to URL in any way other than adding query parameters, but the<br>
libraries are robust to it now. What's new in these library releases<br>
is that the verification is now done on normalized URLs so<br>
meaning-preserving changes do not cause failure.<br>
<font color="#888888"><br>
Josh<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@lists.openidenabled.com">Dev@lists.openidenabled.com</a><br>
<a href="http://lists.openidenabled.com/mailman/listinfo/dev" target="_blank">http://lists.openidenabled.com/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>