fastlane: Did Apple break SPACESHIP_SKIP_2FA_UPGRADE=1?
New Issue Checklist
- Updated fastlane to the latest version
- I read the Contribution Guidelines
- I read docs.fastlane.tools
- I searched for existing GitHub issues
Issue Description
When using match in a CI provisioning update process (that hasn’t changed in a while), we’re suddenly getting Unauthorized Access when spaceship tries to sign into Apple using a non-2FA Apple ID with SPACESHIP_SKIP_2FA_UPGRADE=1 set. It was working two days ago.
Issue occurs with 2.212.1, 2.212.2, and 2.213.0.
The credentials haven’t changed, and I’ve confirmed I can manually login to the portal with the same Apple ID and everything appears to work and it has access to certs/provisioning.
The end of the spaceship logs:
INFO [18:40:42]: >> GET https://appleid.apple.com/account/manage/repair/options: [undefined body]
DEBUG [18:40:43]: << GET https://appleid.apple.com/account/manage/repair/options: 200 {"type"=>"sa", "repairAttribute"=>"hsa2_enrollment", "requiredSteps"=>["hsa2_enrollment"], "allowiCloudAccount"=>false, "phoneNumberRequirementGracePeriodEnded"=>false}
INFO [18:40:43]: >> GET https://appleid.apple.com/account/security/upgrade/setuplater: [undefined body]
DEBUG [18:40:43]: << GET https://appleid.apple.com/account/security/upgrade/setuplater: 200 {"success"=>0, "requiresTerms"=>false, "localLoginUsesAnAppleID"=>false, "clientShouldSetPasscode"=>false, "wasMacTrustedDeviceConverted"=>false, "autoEnrollFailed"=>false, "mandatory"=>false, "notEligibileToJoinFamily"=>false, "requiresiCloudAccount"=>false, "requiresEmailRepair"=>false, "nonFTEUEnabled"=>false, "displayNonUpgradeableDeviceWarning"=>false, "displayIncompatibleDeviceWarning"=>false, "displayInvalidCreditCardWarning"=>false, "accountAlreadyEnrolled"=>false, "displayEligibilityWarnings"=>false, "displayVerificationRequiredWarning"=>false, "incompatibleDeviceWarningAccepted"=>false, "invalidCreditCardWarningAccepted"=>false, "otherOptionsWarningAccepted"=>false, "nonUpgradeableDeviceWarningAccepted"=>false, "verificationRequiredWarningAccepted"=>false, "shouldSuppressDevicePhoneNumbersOffer"=>false, "actionValidationSuccessful"=>false, "successful"=>false}
INFO [18:40:43]: >> POST https://idmsa.apple.com/appleauth/auth/repair/complete: [non JSON body]
DEBUG [18:40:43]: << POST https://idmsa.apple.com/appleauth/auth/repair/complete: 204
INFO [18:40:43]: >> GET https://appstoreconnect.apple.com/olympus/v1/session: [undefined body]
DEBUG [18:40:43]: << GET https://appstoreconnect.apple.com/olympus/v1/session: 401 {"errors"=>[{"id"=>"<masked>", "status"=>"401", "code"=>"NOT_AUTHORIZED.2FA_REQUIRED", "title"=>"An account supporting 2-Factor Authentication is required to log in.", "detail"=>"Your Apple ID needs to be upgraded. Apple requires two-factor authentication to help ensure you're the only person who can sign in to your Apple ID. See: https://appleid.apple.com/manage/security/2sv/enrollment", "links"=>{"see"=>"/login?errorKey=ITC.signin.error.invalidLogin.require2sv"}}]}
WARN [18:40:43]: Auth lost
I’m not sure what a successful log for this used to look like, so it’s hard to guess at what changed / why things have broken, but perhaps some implementation detail that the SPACESHIP_SKIP_2FA_UPGRADE workaround depends on has changed?
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 30
- Comments: 33 (7 by maintainers)
Hello,
There is some good news !
I make a pull request fixing this issue #21317
After some debugging I realized that even with a UI logging / skip 2FA we are no longer able to get an olympus session :
So in case of a 2FA skip, I removed the call to https://appstoreconnect.apple.com/olympus/v1/session and everything seems to working as before in our CI .
No need to provide manually FASTLANE_SESSION ! For now … 🍎 😨
If you can’t wait the merge : https://github.com/AbbyM/fastlane-fix-2fa-olympus/tree/fix-2FA-Skip-olympus
yes same here. It looks like Apple replaced Hashcash with SRP-6a (Secure Remote Password protocol). Thanks Apple for breaking our Enterprise CI builds! Apple should rather focus on App Store Connect APIs for Enterprise Developer Programs!
same, with Enterprise account
We are seeing the same outcome; was working less than 12 hours ago not working now
Any by-when on this update? is this being actively worked on? Looking forward to updates 😃 thanks!
@AbbyM unfortunetly the validity of the session is variable. As stated in the Fastlane’s documentation https://docs.fastlane.tools/getting-started/ios/authentication/
On our side, it seems that our session’s validity is up to a day according to our tests …
We hope that Fastlane’s team will be able to provide a fix for enterpise account that cannot use the app store connect api 🙏
I don’t know how he manage to make it work with “mach” but i found a temporary workaround using FASTLANE_SESSION and FASTLANE_TEAM_ID.
For this you need an Apple-ID account with 2FA activated that is invited to the enterprise team as an admin.
Then you can login with that account in any computer :
fastlane spaceauth -u "apple id mail".Result of that command need to be set in "FASTLANE_SESSION " environment variable in your CI.
“FASTLANE_TEAM_ID” need also to be set to your Enterprise Team ID.
FASTLANE_SESSION are valid for 1 month ( exactly 2592000 seconds) , this is not a fix but a temporary workaround, you still have to perform an action per month.
I didn’t touch a thing in my lanes, just these two env vars.
I have nothing better at this time 😕
Same here when using an Enterprise account!
Same Issue over here… Using Enterprise account…
Hello,
Unfortunatly if you enabled 2FA after this apple breaking change, this fix will not help you and as you say you cant disable it 😕
This issue is all about non-2FA enterprise.
Anyway you can still try to create another account without 2FA and enroll it to your enterprise.
We temporarily circumvent this login issue with
spaceship(for Enterprise), by runningmatchin read-only mode. Don’t know if that’s applicable for other setups though.Hello, I’m investigating and I want to fix it if can.
But FYI: https://github.com/fastlane/fastlane/pull/18116 As @joshdholtz said (⚠️ This may not work into the future when 2FA is hard forced on everyone) when introducing, SPACESHIP_SKIP_2FA_UPGRADE is adhoc solution of old issue so it’s not unexpected we cannot use it now.
The max age in our token also shows
2592000but it expires after 1 day 😕 We really need someone to look at thisHello!? Is anyone paying attention to this? Looking for a ❤️ beat…
Same issue here with our Enterprise account. We really need a fix.