I like that idea. 1. Clarify that the conveyed error message is to be logged and conveyed to the developer, but not to the user. That means it does not need to be internationalized either. It could contain a stack trace as Breno suggests. 2. Identify a bunch of error codes covering common cases, so the receiver can do something meaningful 3. Include a URL, to be given to the user, which points to (unspecified) information on how to solve the problem. Could be help page, tech support line, ... up to the implementor.
On Jan 13, 2010, at 10:20, Allen Tom wrote: > I believe that RPs in general will not be able to automatically recover from > errors (other than to tell the user that something bad happened), so any > error that’s returned will need to be manually interpreted by the RP’s > developer. > > I would like to to see errors returned using standard error codes (machine > readable) along with an URL or string for the owner of the RP to manually > troubleshoot the problem. The string/url should not be displayed to the end > user. This sounds like a very reasonable feature to include in OpenID v.Next. > > Allen > > > On 1/6/10 10:04 AM, "Breno de Medeiros" <[email protected]> wrote: >> >> >> 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. >> >> > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
