Good points. In error cases, DotNetOpenAuth looks for the openid.return_to parameter to decide whether it was a direct or indirect message so that it knows how to return the error to the RP since all indirect messages include a return_to parameter. If that's missing on an indirect message, well, it's invalid for a reason that can't possibly be communicated back to the RP so the best the OP can do is display a message to the user. In this way, invalid openid.mode values can still be reported appropriately both for direct and indirect messages -- at least in my experience.<div>
<br></div><div>Another option might be to look at the Accept headers. If the request mentions that it accepts text/html, it's probably a browser (indirect message), since I don't know of any RP that would send that in its direct message request.</div>
<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Wed, Jan 6, 2010 at 10:04 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since OpenID has a unique endpoint, the only thing separating direct from indirect requests is the openid.mode parameter. In particular, if it's missing the spec does not define how to handle errors. I would argue that in the absence of an openid.ns parameter, an OpenID 2.0 server also has no means to establish how to handle this error reporting feature.<br>
<br>So the error reporting covers the case where the request has valid openid.ns and openid.mode, the openid endpoint is correct, but something else about the request is not valid for some other reason. Most likely, the OP will then provide some feedback such as "The request you sent is invalid", in some default language for the OP. How much value is there in really implementing this feature?<br>
<br>The error reporting feature also requires the OP to report the error code as 400, in violation of HTTP processing rules -- for instance, what if the nature of the error is that the server is overloaded? A 503 should be served then.<br>
<br>I think for developers it would be much more useful to have test OPs that provide detailed error logs (e.g., entire exception stack trace, which production OPs often do not provide), so RP developers can use that for debugging.<br>
<br><br><br><div class="gmail_quote"><div><div></div><div class="h5">On Wed, Jan 6, 2010 at 06:47, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div class="h5">
<div>I stand corrected. A quick look back at the test results is not encouraging. For direct errors I think Yahoo may be the only one I found that passed. Google and MyOpenID are sending back something other than a form encoded response.<div>
<br></div><div>Others are trying to do a redirect to some other page etc. </div><div><br></div><div>For indirect error responses Yahoo is returning the Direct error response. I think that needs work!</div><div><br></div>
<div>I think those tests were added after the last OSIS interop, so most people haven't been through them.</div><div><br></div><div>It is an area that needs some work. </div><div><br></div><div>John B.<div><div></div>
<div><br><div><div>On 2010-01-06, at 11:21 AM, Andrew Arnott wrote:</div><br><blockquote type="cite"><div class="gmail_quote">2010/1/6 John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><div>I have to admit that I have never tested OPs or RPs for processing error messages according to the spec.</div><div><br></div><div>Another thing to add to the tests:)</div></div></blockquote>
<div></div></div><div><br></div>Actually we already have two tests on <a href="http://test-id.org/" target="_blank">test-id.org</a>:<div><span style="font-family:sans-serif,Verdana;font-size:13px"></span><a href="http://test-id.org/OP/DirectMessageErrors.aspx" style="text-decoration:none" target="_blank">OP sends properly formatted error responses to invalid direct request messages</a><br>
<span style="font-family:sans-serif,Verdana;font-size:13px;white-space:normal"></span><a href="http://test-id.org/OP/IndirectMessageErrors.aspx" style="text-decoration:none" target="_blank">OP sends properly formatted error responses via redirect to the RP to invalid indirect request messages</a><br>
<br><div><span style="font-family:sans-serif,Verdana;font-size:13px"><table style="border-width:0px" cellpadding="0" cellspacing="0">
<tbody></tbody></table></span></div></div>
</blockquote></div><br></div></div></div></div><br></div></div><div class="im">_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></div></blockquote></div><font color="#888888"><br><br clear="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>
</font></blockquote></div><br></div>