xcode 当我向 AppStore 提交应用更新时，更新配置文件是否会影响钥匙串访问？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13313715/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Does renewing a provisioning profile affect keychain access when I submit an app update to the AppStore?
提问by Roatin Marth
I have an iPhone app that uses the keychainfor authentication-related storage.
我有一个 iPhone 应用程序，它使用钥匙串进行与身份验证相关的存储。
I also had an expiring Provisioning Profile.
我还有一个即将到期的配置文件。
In the documentation for keychain accessit states:
On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application.
在 iPhone 上，钥匙串权限取决于用于签署应用程序的配置文件。确保在不同版本的应用程序中始终使用相同的配置文件。
Because my Provisioning Profile was expiring, I renewed it (in the provisioning portal), downloaded it, and double-clicked it which "installed" it into XCode's organizer.
因为我的配置文件即将过期，我更新了它（在配置门户中），下载了它，然后双击它“安装”到了 XCode 的管理器中。
After submitting an update to the app to the app store, I'm basically seeing an empty keychain (user's are being asked to log in again).
在向应用商店提交应用更新后，我基本上看到一个空的钥匙串（用户被要求再次登录）。
My question is: does renewing the provisioning profile used to sign an app affect keychain access when the renewed profile is used to submit an update to the app? The docs just say to use "the same provisioning profile", but is unclear about whether a renewed profile counts as a differentprofile (as my experience described above suggests).
我的问题是：当更新的配置文件用于向应用程序提交更新时，更新用于签署应用程序的配置文件是否会影响钥匙串访问？文档只是说使用“相同的配置文件”，但不清楚更新的配置文件是否算作不同的配置文件（正如我上面描述的经验所示）。
What gives?
是什么赋予了？
Update
更新
Solved with help from tc's answer. Looking at the embedded.mobileprovisionfile in each of the .ipas submitted to apple revealed that an expiring certificate and provisioning profile were used to sign version x of the app, and a different certificate and provisioning profile was used to sign version x+1 of the app (culprit: "Automatic Profile Selector" feature of XCode for the Code Signing Identity).
在 tc 的回答的帮助下解决了。查看embedded.mobileprovision提交给苹果的每个 .ipas 中的文件，发现使用过期证书和配置文件对应用程序的版本 x 进行签名，并使用不同的证书和配置文件对应用程序的版本 x+1 进行签名（罪魁祸首：用于代码签名身份的 XCode 的“自动配置文件选择器”功能）。
The 1st certificate and profile were leftover from when a developer used a different iOS Developer Program account to develop an unrelated app (on the same machine, with the same OSX user). Provisioning profiles across multiple iOS developer program accounts are apparently all stored together in ~/Library/MobileDevice/Provisioning Profiles, so they are all candidates for XCode's automatic profile selection feature.
第一个证书和配置文件是开发人员使用不同的 iOS 开发人员计划帐户开发不相关的应用程序（在同一台机器上，使用相同的 OSX 用户）时遗留下来的。跨多个 iOS 开发者程序帐户的配置文件显然都存储在 中~/Library/MobileDevice/Provisioning Profiles，因此它们都是 XCode 的自动配置文件选择功能的候选者。
I changed the code signing identity by selecting a totally differentdistribution profile that I mistook as a renewed/valid version of the expiring distribution profile, and submitted an update. Same app, different cert, different provisioning profile == empty keychain. D'OH.
我通过选择一个完全不同的分发配置文件来更改代码签名身份，我将其误认为是过期分发配置文件的更新/有效版本，并提交了更新。相同的应用程序，不同的证书，不同的配置文件 == 空钥匙串。哦。
回答by tc.
The keychains you're allowed to use is determined by keychain-access-groupsin the entitlements, which is limited to a subset of the keychain-access-groupsin the provisioning profile, which is determined by the "bundle seed"/"prefix"/ (ApplicationIdentifierPrefixin the provisioning profile), set in the "App ID".
您被允许使用的钥匙串由keychain-access-groups权利决定，该权利仅限keychain-access-groups于配置文件中的子集，由“捆绑种子”/“前缀”/（ApplicationIdentifierPrefix在配置文件中）确定，设置在“应用程序 ID”中。
Assuming you've kept the old submitted app (or have the .ipafrom iTunes, which is just a zip), look at embedded.mobileprovisionin both the old and new apps (less Foo.app/embedded.mobileprovisionin a terminal should do the trick, or you can open it in a text editor although sometimes they'll pick the wrong line endings). You're looking for something like this (you may see extra keys for push/iCloud):
假设您保留了旧提交的应用程序（或.ipa来自 iTunes，它只是一个 zip），请查看embedded.mobileprovision旧应用程序和新应用程序（less Foo.app/embedded.mobileprovision在终端中应该可以解决问题，或者您可以在文本编辑器中打开它尽管有时他们会选择错误的行尾）。您正在寻找这样的东西（您可能会看到推送/iCloud 的额外键）：
<key>Entitlements</key>
<dict>
<key>application-identifier</key>
<string>A1B2C3D4E5.com.example.MyApp</string>
<key>get-task-allow</key>
<false/>
<key>keychain-access-groups</key>
<array>
<string>A1B2C3D4E5.*</string>
</array>
</dict>
You can also view the actual entitlements your app was signed with:
您还可以查看您的应用签署的实际权利：
codesign -d --entitlements - Foo.app/Foo | vis
IIRC the keychain access groups default to e.g. A1B2C3D4E5.com.example.MyApp, but you can set this to anything you want provided it matches A1B2C3D4E5.*(Xcode 4 even has a nice GUI entitlements editor). If the bundle prefix is different, that'll cause the problem you're seeing. I thinkyou can change it back provided you haven't enabled push/Game Center/etc.
IIRC 钥匙串访问组默认为 eg A1B2C3D4E5.com.example.MyApp，但您可以将其设置为您想要的任何匹配项A1B2C3D4E5.*（Xcode 4 甚至有一个不错的 GUI 权限编辑器）。如果捆绑包前缀不同，则会导致您看到的问题。我认为您可以将其改回，前提是您尚未启用推送/游戏中心等。
回答by rmaddy
As long as your app's bundle id doesn't change there won't be any issue with the keychain.
只要您的应用程序的 bundle id 没有改变，钥匙串就不会有任何问题。
Considering that we all have to renew our certificates and distribution profiles every year, it would be chaos if doing so broke the keychain access for our apps.
考虑到我们每年都必须更新我们的证书和分发配置文件，如果这样做会破坏我们应用程序的钥匙串访问，那将会很混乱。
I have one app that's been in the App Store for over 4 years. It uses the keychain. It has been updated several times over the years, many times with an updated provisioning profile. There have been no keychain issues.
我有一款应用在 App Store 已超过 4 年。它使用钥匙串。多年来，它已多次更新，多次更新了配置文件。没有钥匙串问题。
回答by Michael Baltaks
For anyone else searching, I had a different issue. The manual steps I followed to resign the ipa resulted in it having no entitlements, which means no keychain access. So I created a script to resign the ipa but keeping the entitlements from the original. I posted it at http://baltaks.com/2013/08/resigning-enterprise-ios-appsand will keep that updated if required.
对于搜索的其他人，我遇到了不同的问题。我退出 ipa 所遵循的手动步骤导致它没有权利，这意味着没有钥匙串访问权限。所以我创建了一个脚本来退出 ipa 但保留原始权利。我将其发布在http://baltaks.com/2013/08/resigning-enterprise-ios-apps并将在需要时保持更新。
