> But the code suggests that the module worked fine and made the > determination not to authorize the user. If that's so, then why do we > have the errdetail at all? Can't we just get rid of it and let the > errmsg stand on its own merit?
This also confused me when I worked on our validator plugin. But the validator has two places to return failure: * res->authorized, which should be true if we are allowed to continue with the login, false if not * and the return value, which should be true if the validation process completed successfully, false if not At least that's how I understand it. This check is about the first one, which means there wasn't any problem during the validation process, but the validator decided not to allow the login to proceed. I also want to add that these error messages are not that useful for figuring out what went wrong. In practice, the validator has to report more specific error messages before this happens, otherwise the user won't be able to figure out why we are rejecting some login. (both for internal errors and rejecting authentication) And if it reports an error, and stops the code flow, these won't be displayed at all - but then why do we have all these bool outputs in the validator? And even the messages in the caller code are WARNING/LOG. The intention of the API seems to be to report WARNINGs for validation failures, even internal errors, so for now we added most error checks in the validator as that, allowing the code to continue.
