Changed state and email fields to optional to match Apple's responses

[intonarumori]

In this PR we updated the model objects to match Apple's responses.

The Issue

We were getting errors with the library if we omitted the state parameter in our call to getIDCredential or we were hiding our email address in the Apple Sign-in dialog. The error was pretty obscure:

TypeError: Instance of '_TypeError': type '_TypeError' is not a subtype of type 'JSObject'

What was actually happening

• We omitted the state parameter when calling getIDCredential and then hid the email in the Apple Sign-in dialog
• The state and email fields were omitted in the JS response from Apple
• toDart here could not parse the JS object because the state and email fields were defined as required fields and not optionals in UserI and AuthorizationI
• An informative parsing error was raised:

TypeError: null: type 'Null' is not a subtype of type 'String'

• The catch block is only accounting for errors coming from Apple when trying to convert the error to SignInErrorI here
• This failed, so another error was raised:

TypeError: Instance of '_TypeError': type '_TypeError' is not a subtype of type 'JSObject'

• This obscured the original informative error message

The solution

• state field has been updated to be optional: state is defined as optional when calling getIDCredential here. When not passing it, Apple will omit it in their response, thus it should be an optional field on AuthorizationI.

• email field has been updated to optional: In various circumstances (ex. when the user uses Apple sign-in with their email hidden) this field might be omitted in the response from Apple. Thus this should also be defined as optional in UserI.

Couple of questions remain

• Should we do the same for name.firstName and name.lastName?
  So far we were not about to clear any of these fields so it seems they are always provided, however it's hard to know we really covered all edge cases.
• Should we improve the code in the catch block here so if parsing errors in the future arise we get more informative error messages and can fix them quicker?

[tp]

@intonarumori Thanks for the thorough investigation.

Surely I was always testing with a state parameter, so it might be that the types here are wrong.

I will verify this locally and if it fixes the state-less and/or "second login" flow as you describe, will prepare a release ASAP.

[tp]

Should we do the same for name.firstName and name.lastName?

I think that is already working fine because the whole name object is optional, and thus won't error when this is omitted.

[tp]

Just tested this on web without any requested scopes (no name or mail), and without passing a nonce or state either.

Before (on master) it failed, and with this fix it worked fine.

So thanks a ton @intonarumori!

[tp]

Should we improve the code in the catch block here so if parsing errors in the future arise we get more informative error messages and can fix them quicker?

Yes, that would be a great follow-up. The code should not assume that it's only that specific error type. Will have to check whether an is check would work on there, and if it doesn't match forward the "raw" error.

[brian-superlist]

Heya, we ran into this as well at Superlist. I have upgraded to the master branch and found everything now works as expected. Just a heads up it'd be helpful to publish a new version of the sign_in_with_apple_web package as I'm sure other folks will run into this bug as well.

Thanks for the package and consideration!

[tp]

@brian-superlist These changes were already released with 6.1.2: https://pub.dev/packages/sign_in_with_apple/changelog

Maybe you were on 5.x.x before, and thus the switch to master helped?

[brian-superlist]

@tp Thanks for the heads up, but I don't think that is correct..

We were on 6.1.2, but these changes were not released with that version. This change affects the sign_in_with_apple_web plugin, not the sign_in_with_apple plugin. The web plugin was last updated 8 months ago and does not include these changes: https://pub.dev/packages/sign_in_with_apple_web/versions

Therefore, in our pubspec, I manually override only the sign_in_with_apple_web plugin to point to master. That's the package that I'd recommend deploying a new version of

[tp]

@brian-superlist You are right 🙈 I missed the need to publish and update the reference to sign_in_with_apple_web when doing the release of the "parent package".

This has now been fixed and the latest https://pub.dev/packages/sign_in_with_apple/versions/6.1.4 now pulls in a fresh release of the web part.

Thanks for bringing this up :)