在向AppStore提交应用更新时，更新配置文件会影响钥匙串访问吗？ [英] Does renewing a provisioning profile affect keychain access when I submit an app update to the AppStore?

问题描述

我有一个iPhone应用程序使用与身份验证相关的存储的钥匙串。

I have an iPhone app that uses the keychain for authentication-related storage.

我还有一个即将到期的配置文件。

I also had an expiring Provisioning Profile.

在钥匙串访问的文档它声明：

在iPhone上，钥匙串权利取决于配置文件用于
签署您的申请。请确保在不同版本的应用程序中始终使用相同的
配置文件。

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.

由于我的配置文件已过期，我更新了它（在配置门户中），下载了它，然后双击它安装到XCode的组织者。

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.

在向应用程序提交更新后应用程序商店，我基本上看到一个空的钥匙串（要求用户再次登录）。

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 different profile (as my experience described above suggests).

给出了什么？

更新

在tc的回答的帮助下解决了。查看提交给苹果的每个.ipas中的 embedded.mobileprovision 文件，显示已过期的证书和配置文件用于签署应用程序的x版本，并且不同证书和配置文件用于签署应用程序的版本x + 1（罪魁祸首：XCode的自动配置文件选择器功能，用于代码签名标识）。

Solved with help from tc's answer. Looking at the embedded.mobileprovision file 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).

第1个当开发人员使用不同的iOS Developer Program帐户开发不相关的应用程序（在同一台机器上，使用相同的OSX用户）时，证书和配置文件是剩下的。多个iOS开发者计划帐户中的配置文件显然都存储在〜/ Library / MobileDevice / Provisioning Profiles 中，因此它们都是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.

我通过选择完全不同的分发配置文件来更改代码签名身份，我将其误认为已过期的分发配置文件的续订/有效版本，并已提交更新。相同的应用程序，不同的证书，不同的配置文件==空钥匙串。 D'OH。

I changed the code signing identity by selecting a totally different distribution 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.

推荐答案

您可以使用的钥匙串由 keychain-access-决定权利中的组，仅限于配置文件中 keychain-access-groups 的子集，由捆绑确定种子/前缀/（ ApplicationIdentifierPrefix 在配置文件中），在应用程序ID中设置。

The keychains you're allowed to use is determined by keychain-access-groups in the entitlements, which is limited to a subset of the keychain-access-groups in the provisioning profile, which is determined by the "bundle seed"/"prefix"/ (ApplicationIdentifierPrefix in the provisioning profile), set in the "App ID".

假设您保留了旧提交的应用程序（或者从iTunes获得 .ipa ，这只是一个zip），请查看 embedded.mobileprovision新旧应用程序中的（终端中的 less Foo.app/embedded.mobileprovision 应该可以解决问题，或者你可以打开它一个文本编辑器，虽然有时他们会选择错误的行结尾）。你正在寻找这样的东西（你可能会看到push / iCloud的额外密钥）：

Assuming you've kept the old submitted app (or have the .ipa from iTunes, which is just a zip), look at embedded.mobileprovision in both the old and new apps (less Foo.app/embedded.mobileprovision in 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):

    <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钥匙串访问组默认为例如 A1B2C3D4E5.com.example.MyApp ，但您可以将其设置为您想要的任何内容，只要它符合 A1B2C3D4E5。* （ Xcode 4甚至还有一个很好的GUI权利编辑器。如果捆绑前缀不同，那将导致您看到的问题。如果您没有启用推送/游戏中心/等，我认为您可以将其更改回来。

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 think you can change it back provided you haven't enabled push/Game Center/etc.

这篇关于在向AppStore提交应用更新时，更新配置文件会影响钥匙串访问吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！