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.
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. -- Andrew Arnott "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 On Wed, Jan 6, 2010 at 10:04 AM, Breno de Medeiros <[email protected]> wrote: > 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. > > 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? > > 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. > > 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. > > > > On Wed, Jan 6, 2010 at 06:47, John Bradley <[email protected]>wrote: > >> 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. >> >> Others are trying to do a redirect to some other page etc. >> >> For indirect error responses Yahoo is returning the Direct error response. >> I think that needs work! >> >> I think those tests were added after the last OSIS interop, so most >> people haven't been through them. >> >> It is an area that needs some work. >> >> John B. >> >> On 2010-01-06, at 11:21 AM, Andrew Arnott wrote: >> >> 2010/1/6 John Bradley <[email protected]> >> >>> I have to admit that I have never tested OPs or RPs for processing error >>> messages according to the spec. >>> >>> Another thing to add to the tests:) >>> >> >> Actually we already have two tests on test-id.org: >> OP sends properly formatted error responses to invalid direct request >> messages <http://test-id.org/OP/DirectMessageErrors.aspx> >> OP sends properly formatted error responses via redirect to the RP to >> invalid indirect request >> messages<http://test-id.org/OP/IndirectMessageErrors.aspx> >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
