-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
[spaceship] decrease App Store Connect API token issued-at-time
to prevent server rejection
#21583
[spaceship] decrease App Store Connect API token issued-at-time
to prevent server rejection
#21583
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
It would be great to have this merged. I'm receiving this error very often sadly... |
Same here... please lets get that merged! |
For some reason this started to happen more and more. PS. In our case macos build agents are provided by CI and cannot be managed from our side, so it's not possible to sync/change time. Just restart the build on another agent, where it then works fine. |
De release pipeline voor iOS geeft een authenticatie error. Het is een bekend probleem dat dit niet een echte error is, maar veroorzaakt wordt doordat de tijd van de aanvrager (Azure server) en de issuer (Apple server) out of sync zijn. Daardoor is de token verlopen zodra die is uitgereikt... De fix is om deze sessie duur voor de token aanvraag te verhogen. Uit de spaarzame documentatie en GitHub issues meen ik op te maken dat de max 1200 ms is, dus daar zet ik 'm op zolang er geen echte fix is. Er is wel een PR met een mogelijke fix (fastlane/fastlane#21583), die houd ik in de gaten, wordt vervolgd.
Guys can we just merge this PR please ? It's critical for our builds. |
One more approval review let's go! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Let's get this merge with the next release!
Hi @max-ott , do you know when the next release is planned? Thanks in advance |
Using this workaround, till this fixed is merged:
|
I am currently testing by pointing Gemfile to the branch for this PR:
I am comparing the success rate by running the same workflow on schedule in two different repositories. One with the proposed changes, the other without. I can verify that the PR helps, but unfortunately, I am also seeing failures due to the same error when testing the PR. It seems like there can be more than 60 second time offsets between the GitHub macos-13 runner and the Apple servers. Perhaps the limit should be extended. There ismention of >200 seconds time difference in actions/runner#2996, in case that is the same underlying problem. The error I get is this: Results: With this PR: Initial testing of adding the 'Sync clock' step as mentioned by @b099l3 looks promising though. Edit: Results from testing 'Sync clock' is reported here: actions/runner#2996 (comment) |
This is a good solution to an annoying problem! Let's merge this PR, please 👍 |
The root cause with GithHub runner machine clocks should already have been sorted: actions/runner#2996 (comment). Are you still seeing this type of failures? |
issued-at-time
to prevent server rejection
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was on the fence in the beginning but this solution seems simple, efficient, and safe, IMO. LGTM 💪
Thanks for fixing this, @xinsight! I see a lot of people are facing this issue 🙏
I think this change is redundant by now. Please see actions/runner#2996 (comment) |
Thanks for pointing that out @bjornoleh ! That seems to solve this issue for everyone using fastlane with GitHub Actions, but might not be the case for other CI providers? I'm ok with closing this PR if everyone facing this issue were GHA users though 😮 From a quick search, it seems like #21109 OP was experiencing this in Jenkins 😬 |
No, I'm using Fastlane on a custom CI/CD server and started facing auth rejects from Apple last week. So I'm very much interested in merging this PR. Syncing time with apple server works for the first command (upload_to_testflight), but next command (waiting for build processing and then setting distributing groups) fails again with the same error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's add this.
Checklist
bundle exec rspec
from the root directory to see all new and existing tests passbundle exec rubocop -a
to ensure the code style is validci/circleci
builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)Motivation and Context
I have observed sporatic failures with delivering builds to testflight that result in an error message like this:
After much debugging and with this tip I confirmed that my machine time was slightly ahead of Apple's servers which caused the AppStore Connect token to be rejected as the issued-at-time was in the future.
Similar issues have been reported in #20516 and #21109.
Syncing servers to Apple's servers (using ntp.apple.com) is one solution to this problem, however, not everyone is able or willing to sync their system's clocks to Apple's (and Apple's servers might be out-of-sync!) so a more robust and permanent solution is needed.
Description
By reducing the issued-at-time (iat) in the jwt token, the token will only be rejected if a machine is over a minute in the future. (This value could of course, be increased, but one minute seems like a good starting point.)
Additionally, this fix also addresses a minor race condition in the unit tests where the issued time was being compared to the current time - which would fail if the clock second changed from the time when the token was generated to when the test was run.
Testing Steps
To reproduce this issue, add 60 seconds to the
iat
value in the payload in: https://github.com/fastlane/fastlane/blob/master/spaceship/lib/spaceship/connect_api/token.rb#L103 Attempting to perform any action that requires a token with spaceship will fail.For example:
Repeat the command by removing 60 seconds from iat and it should pass.