Errors are thrown when a requirement is not met. The requirement is validated by comparing expected data with actual data. *ERROR MESSAGES MUST REPORT EXPECTED AND ACTUAL DATA* Example: * BAD => "ext.authorizedScopes oversteps your scopes" Why? A check has been made that ext.authorizedScopes is a subset of your scopes, and this check has failed. In order to check this, the program has determined what your scopes are, and what ext.authorizedScopes are - and when the condition was not met, it just said what the test was - but it did not tell you what data it processed. * GOOD => "ext.authorizedScopes oversteps your scopes. Your scopes: 'a', 'b', 'c'. ext.authorizedScopes: 'a', 'c', 'd'." *ALL* error messages should provide the relevant data that demonstrates the failed condition that they are reporting, since a consumer of this error can only benefit from it, when it knows what the data was that caused the problem. This was just an example - this bug is a tracking bug for all such violations we find of this general principle.
A very important caveat here, as mentioned by Dustin, is that that policy should only be followed insofar as it doesn't compromise security. An example would be avoiding exposure of security hashes. For the most part though, relevant information can be divulged, such as missing scopes, which clientId was used, etc.
Summary: Tracking bug - provide context in error messages → [tracking] provide context in error messages
Are there any additional bugs to track here? Or can we close this?
Our code is littered with them, but maybe a tracking bug doesn't make so much sense, as it is more like a bug classification, rather than a goal which depends on a set of other open bugs. I'd also forgotten I created it! :)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.