如何解决“权利‘钥匙串访问组’”问题具有配置文件不允许的值”
我在我的应用程序中使用钥匙串，当以 AdHoc 方式运行应用程序时出现此错误。当我使用调试器（使用开发人员配置文件）运行它时，它不会出现。如果应用程序已安装在设备上，并且我从 Xcode 再次安装它，那么我会注意到该应用程序无法访问钥匙串。这肯定是因为这些错误而发生的。
我花了很多时间在谷歌上搜索该错误，有些人建议添加带有钥匙串访问组的权利文件。但我找不到任何苹果文档或任何合理的解释什么权利文件需要。
有人可以帮我解决吗？
I am using keychain in my app and I get this error when run app as AdHoc. It doesn't appear when I run it with debugger (with developer provisioning profile). If app has already been installed on the device and I install it again on top of it from Xcode then I notice that app doesn't have access to keychain. It happens certainly because of those error.
I have spent much time googling that error and some recommends to add entitlements file with keychain-access-group in it. But I could not find any Apple doc or any reasonable explanation what entitlements file needed for.
Can someone help me to solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这里有一篇很旧的帖子
您需要有权说明您的应用程序的捆绑包种子位于哪个捆绑包标识符下，因为这是 KeyChain 允许您的应用程序访问它的方式。
一旦两个应用程序在其捆绑种子中具有相同的捆绑标识符，它们就可以共享 KeyChain 访问权限。
因此，如果应用程序 A 具有公共捆绑 ID：
com.yourcompany.AAAAAA
并将应用程序 B 作为 Common Bundle Id
com.yourcompany.BBBBBB
如果他们的 .ipa 中都有一个权利文件
（plist 包含一个键为“keychain-access-groups”的数组，其中包含字符串“.com.yourcompany.AAAAA”和
.com.yourcompany.BBBBB”）
他们可以共享 KeyChain 访问权限。
There is a pretty old post here
you need the entitlements to say which Bundle Identifier you App's Bundle seed is under since that is the way KeyChain allows your application to access it by.
Once two Applications have the same Bundle identifier in their bundle seed, they can share KeyChain access..
So if Application A has a Common Bundle Id:
com.yourcompany.AAAAAA
And application B as a Common Bundle Id
com.yourcompany.BBBBBB
And if they both have an entitlements file in their .ipa
(plist containing an array keyed "keychain-access-groups" with a string ".com.yourcompany.AAAAA" and
.com.yourcompany.BBBBB")
They can share KeyChain access..
我找到了解决方案。 adHoc 和 Debug 配置文件的 appID 前缀似乎不同。
假设我们有以下 AppId：
a.com.mycompany.A（临时构建）b.*（调试/开发构建）第二个 id 是由 Xcode 创建的其前缀用于对应用程序的调试版本进行签名。
第一个 id 用于签署应用程序的 AdHoc 版本。
如果您现在尝试通过访问组
a.com.mycompany使用钥匙串，您将获得 AdHoc 版本的钥匙串访问权限。如果您使用访问组b.com.mycompany，您可以在调试版本中获得访问权限。它们都不适合两者。我通过创建一个新的通配符 id：a.* 并将其用于“iOS 团队配置文件：*”解决了该问题。似乎这个配置文件以某种方式用于签署应用程序的调试版本。我实际上认为它使用开发配置文件来签名？！
但是，通过此更改，我能够使用相同的访问组在调试和临时模式下访问钥匙串。
看起来新注册用户不会遇到这个问题，现在 Xcode 会自动创建一个带有正确前缀的 id。
I found a solution. The appID prefix seems to be different for adHoc and Debug profiles.
Let's assume we have the following AppIds:
a.com.mycompany.A(ad hoc builds)b.*(debug/development builds)The second id was created by Xcode and its prefix is used to sign the debug version of the app.
The first id is used to sign the AdHoc version of the app.
If you now try to use the keychain with the accessgroup
a.com.mycompanyyou get keychain access for the AdHoc version. If you use the accessgroupb.com.mycompanyyou get access in the debug version. None of them work for both.I solved the Problem by creating an new wildcard id: a.* and using it for the "iOS Team Provisioning Profile: *". It seems that this provisioning profile is somehow used to sign a debug build of the app. I actually thought it uses the Development Provisioning Profiles to sign it ?!
However, with this change I was able to access the keychain in debug and adHoc mode with the same access group.
It seems like new registered users don't run into this problem, now Xcode automatically creates an id with the right prefix.
除了上面提到的解决方案之外，我还遇到了这个问题的不同变体。
我的组织标识符发生了变化（可能与接受developer.apple.com上的最新协议更新有关），因此我的应用程序的前缀发生了变化。因此，以前可能是
ABCCYZ0U812.com.whatever.app现在是90210SUXX11.com.whatever.app当我去提交时，您会看到屏幕上写着“发送（应用程序名称）到 Apple”，并且有一个名为“二进制和权利”的列表，当我在我的应用程序下展开该列表时（两次，因为我猜 Xcode 第一个有一个错误）时间）我会看到类似的内容
，因此出于某种原因，它仍然使用旧的团队标识符作为
keychain-access-groups位，但现在与新的团队标识符不匹配我做了以下
现在一切都匹配并且工作正常
可能有一种更微妙的方法来修复它而不删除所有内容但这应该会让您走上正确的轨道。
In addition to the solutions mentioned above, I ran into a different variant of this issue.
My organization identifier changed (may be related to accepting the latest agreement update on developer.apple.com) and so the prefix for my app changed. So whereas before it was maybe
ABCCYZ0U812.com.whatever.appnow it was90210SUXX11.com.whatever.appWhen I went to go submit and you get the screen that says "Sends (app name) to Apple" and there's a listing called "Binary and Entitlements", when I would expand the listing under my app (twice, since I guess Xcode has a bug the first time) I would see something like
So for some reason it was still using the old team identifier for the
keychain-access-groupsbit but that now didn't match the new team identifierI did the following
Now everything matched and it worked
There may be a more delicate way to fix it without deleting everything but that should put you on the right track.
遇到了同样的问题和其中的几个变体（错误 ITMS-90164 等）。在摆弄了几个小时的各种设置后，无济于事，我最后不情愿地遵循了 Apple 的技术问答 QA1814：设置 Xcode 以自动管理您的配置文件。这些步骤非常简单明了，配有屏幕截图以及完成更改后回收 Xcode 的重要说明。最重要的是，它解决了我的问题，并允许我最终将我的存档上传到 App Store。
In ran into this same issue and several variations therein (error ITMS-90164, among others). After fiddling with various settings for hours, to no avail, I finally, reluctantly, followed Apple's Technical Q&A QA1814: Setting up Xcode to automatically manage your provisioning profiles. The steps are very simple and straightforward, complete with screenshots and the ever-important note to recycle Xcode after you're done making the changes. Most importantly, it resolved my issue(s) and allowed me finally to upload my archive to the App Store.
正如其他答案中提到的，这是由于使用了错误的配置文件造成的。
我在 Xcode 6 中遇到了这个问题。我的项目中有两个目标，无论我做什么（包括更改构建设置中的配置文件设置），其中一个总是使用错误的配置文件构建。
经过几个小时的使用，我注意到以下内容：
我不知道其中任何一个来自哪里，但我解决问题的方法是：
之后，它就起作用了。
As mentioned in the other answers, this is due to the wrong provisioning profile being used.
I had this problem in Xcode 6. I had two targets in my project, and one of them always built with the wrong profile, no matter what I did (including changing the Provisioning Profile setting in Build Settings).
After hours of playing around with it, I noticed the following:
I don't know where either of these came from, but what I did to fix my problem was this:
After that it worked.