Explicit types/codes for errors
idomo1 opened this issue · 9 comments
Describe the feature request?
The old SDK uses explicit types for errors. For our use case, we map these errors to error codes so we can corroborate user reports with our crash logs. We don't use the error message itself to not expose information that could be used to aid a malicious user.
This new SDK is using a generic Error types with strings, which makes this approach brittle since strings can be changed without any obvious sign.
It would be great if the errors could be distinguished by type or by codes.
New or Affected Resource(s)
No idea
Provide a documentation link
No response
Additional Information?
No response
I'm interested to hear more about your use case.
I think we have specific exception subclasses for everything that would be useful.
What errors are you hoping to differentiate?
On a deeper look, you're right, there is a lot there already.
Broadly we want to differentiate authentication vs authorisation errors vs device storage errors (e.g encryption) and unable to find browser errors. Then also the different errors in those categories.
It looks like if the browser can't be found a ActivityNotFoundException would be thrown so that's okay. The old SDK has AuthorisationException, AuthenticationException and EncryptionError classes which makes the broad categorisation easier. I haven't exhaustively looked at the code but I don't think there is an equivalent?
One example which I found is IdTokenValidator.Error which has explicit enums defined in the old SDK, but just has different strings for each type of error in this SDK. If we get "Issued at time is not within the allowed threshold of now.", vs say an "Invalid issuer" it may be a very different issue (wrong device date and time vs something else).
Thanks for digging in, I appreciate the feedback.
There are many different types of errors that can be thrown from within the SDK. Broadly speaking, I wouldn’t expect an application developer to do much with most of them outside of reporting to a crash reporting tool to monitor. Some errors (network issues) are going to be expected, some are going to be issues with user devices (wrong device time), some are going to be developer errors (incorrect SDK usage, etc), bugs, or even someone trying to abuse the app via malicious activity. I probably missed some categories, but within each of these categories there could be multiple errors that happen.
As an application developer, I wouldn’t worry about handling all of the different types of errors. That being said, I know developers are going to what to be able to identify different types of errors to change behavior of the application in some way (potentially different error messages, etc).
Enums aren’t a great solution for SDKs because it’s easy to break source and binary compatibility when changing them.
That being said, I do think we can improve on the ability to identify certain exceptions. You’ve mentioned the IdTokenValidation issued at time threshold, and I agree that’s one that would be nice to identify outside of string matching.
Do you have any other examples of exceptions you’d like to be able to easily identify?
Thank you for being so open to feedback 😄 . W.r.t the implementation, it could be as simple as adding some id in the string message. Just as long as there's something identifiable which won't change with SDK updates.
😄Are there any other examples you have in your application on exceptions you need better differentiation on?
One important one which we're using string matching for atm is "User is not assigned to the client application"
For user not assigned to application, you can still match on that based on the exception message from the type AuthorizationCodeFlow.ResumeException. There is another error that comes back from the server that is "access_denied", which we can expose in that exception if that would be helpful.
Yeah that would be great, exposing error ids in general when not already defined by an explicit type would be really helpful
See #184 for exposing error ids, and I'm still working on a solution for the id token validation errors. Please let me know if you think of anything else that needs exposed.