-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ErrorCode 17999 #12808
Comments
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. |
Hi @jostster, which App Check provider(s) are being used in the project? |
We are using |
Looks like more users are seeing this according to our support team. Users have stated they haven't changed devices but maybe they have restored from backup or for some reason the system is holding on to an old token? |
In the case where the backup is creating the invalid state, the proposed fix for #12629 may address this. |
That is a possibility but I didn't see anything from that issue about 17999 error code. We have also asked users with this issue to delete and reinstall the application which they say isn't resolving their issue. I have added back code into our next release that will reset the attest key when a 17999 occurs. We will see if that resolves the issue. |
@jostster, from the reports you've seen, does this seem like an issue that won't go away once it starts happening? |
@ncooke3 it seems hit or miss. Some are saying that reinstalling the app does not resolve the issue while others that specifically stated, they bought a new phone and restored from cloud said that deleting and reinstalling did fix the issue. |
Hi @jostster, I just released an update for a core dependency of Firebase App Check. See #12629 (comment) |
Hi @jostster, are you still facing this issue with the AppCheckCore dependency bumped to 10.19.1? #12629 (comment) |
@ncooke3 I haven't had a chance to implement it as it wasn't available in the latest release version at the time. I am on PTO but will add it into our June release |
Hey @jostster. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically. If you have more information that will help us get to the bottom of this, just add a comment! |
I also getting this error, I didn't change any code, and it worked in the morning. [log] e.message Error Domain=FIRAuthErrorDomain Code=17999 "An internal error has occurred, print and inspect the error details for more information." UserInfo={FIRAuthErrorUserInfoNameKey=ERROR_INTERNAL_ERROR, NSLocalizedDescription=An internal error has occurred, print and inspect the error details for more information., NSUnderlyingError=0x3029a9fe0 {Error Domain=FIRAuthInternalErrorDomain Code=3 "(null)" UserInfo={FIRAuthErrorUserInfoDataKey={length = 1628, bytes = 0x3c21444f 43545950 45206874 6d6c3e0a ... 2e3c2f69 6e733e0a }, NSUnderlyingError=0x3029a2610 {Error Domain=com.google.HTTPStatus Code=403 "(null)" UserInfo={data={length = 1628, bytes = 0x3c21444f 43545950 45206874 6d6c3e0a ... 2e3c2f69 6e733e0a }, data_content_type=text/html; charset=UTF-8}}}}}
|
UPDATE This error comes when device connect to VPN. If VPN is off its working. What is the issue? |
Hey @jostster. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically. If you have more information that will help us get to the bottom of this, just add a comment! |
Since there haven't been any recent updates here, I am going to close this issue. @jostster if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this. |
Reopening as this is still an issue. |
Hi everyone, I have these token failures to Apple (FB13812838) and am still awaiting a response. I will follow-up and report back as I learn more. |
For confirmation we had one user that updated their iOS version and was locked out because of the AppCheck. We asked them to uninstall our app, then reinstall it from the AppStore and they got back to us saying that reinstalling allowed them to get back in. |
@ncooke3 is it possible for firebase to request a new token on these failures? With iOS 18 out now, and as users are updating, they are contacting our support with this error that the AppCheck is giving them a 17,999 error. Really the only thing we can try is having them delete the application and reinstall it from the app store and hope that fixes it for them. |
Yes @jostster, I will look into this ahead of the next release. I suspect this is due to the SDK storing an app attest artifact in user defaults, which is included in iCloud backups. Since the artifact is device specific, I suspect this may explain this failure path that upgrading customers are experiencing. |
Thanks @ncooke3 . I'm curious, is there a different key as I created this little hack as a work around which did work before but with this still in our application and users still encountering this error, I was curious if there is another place I should be resetting the token.
|
Hi @jostster, I mixed up my thoughts as the retry logic to wipe out the key ID was already implemented last year to address #11926. Since reinstalling the app seems to fix the issue, I'm trying to tease out what persistent state is the culprit. Two additional questions to clarify some details.
|
We do use the debug app attest provider, but that is only for dev builds. For production where we are seeing this issue we only use the default |
Hi @jostster, reCAPTCHA could be a solution to consider. It is documented to use Apple's App Attest, so if App Attest is the underlying issue here, then similar failures could occur. When the Auth SDK makes a request (e.g. password login), an app check token is requested to include in the request. Tokens can be requested with and without forcing a refresh of the token. In Auth's case, app check token's are not force refreshed, so whatever token is cached will be included in the request. This is done to be as performant as possible. In this case though, I think it could make sense to retry the sign in request with a fresh app check token to see if that fixes the issue or at least provides some more clues as to what is going wrong. Here's an example of what this could look like: Task {
do {
try await Auth.auth().signIn(withEmail: email, password: password)
} catch let error as NSError {
// Catch the App Check related error, force refresh the stored App
// Check token, and make retry signing in.
guard error.code == AuthErrorCode.internalError.rawValue else {
throw error // Error is unrelated (e.g. account does not exist).
}
// This call will fetch a new app check token and reset the cached
// attestation artifacts if needed.
_ = try await AppCheck.appCheck().token(forcingRefresh: true)
// Retry the sign in. This should pick up the new, refreshed token.
try await Auth.auth().signIn(withEmail: email, password: password)
}
} |
Thanks @ncooke3 I was looking at the |
I don't think so because the Auth SDK uses |
@jostster, if you would like, I can take a closer look into the logs to better understand which part of the App Attest handshake is failing. I just need a project number. Feel free to send it to |
Sent, ty! |
Hi @jostster, after a closer look, I think this may be #12468 surfacing when the the Auth SDK requests the App Check token. If the App Check token cannot be successfully retrieved, then the App Check SDK will give a place holder token to include that will result in the error message given. Today I released a fix similar to what was done in #11926. Please take a look at my comment in the corresponding issue for updating instructions: #12468 (comment) I'm going to mark this issue as closed, but we can re-open if the persists. |
Description
iOS users randomly receive ErrorCode 17999
Could be a regression of #11926 which was fixed. I am unable to replicate this locally but many users are saying they are encountering this with some saying a re-install isn't resolving it.
I feel that the AppCheck token isn't being re-generated when a 17999 error is received.
Reproducing the issue
Unable to repro locally, but users just attempt to login with username / password using
signInWithEmailPassword
with AppCheck enabled.Firebase SDK Version
10.23.1
Xcode Version
15.3
Installation Method
Swift Package Manager
Firebase Product(s)
App Check, Authentication, Crashlytics, DynamicLinks
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
Expand
Package.resolved
snippetIf using CocoaPods, the project's Podfile.lock
Expand
Podfile.lock
snippetReplace this line with the contents of your Podfile.lock!
The text was updated successfully, but these errors were encountered: