在Provisioning Portal中创建应用程序组ID时(或现在称为其中的任何内容),它会显示“为应用程序组输入唯一标识符,从字符串'group'开始”并且似乎在条目中强制执行领域。此外,许多示例代码使用app group id字符串,例如“group.com.company.blah”。
但是,我看到的最终部分链接到整个文档, App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory和Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group直接与此相矛盾,明确指出“必须从您的开发团队ID开始,然后是一段时间”。
这些部分中给出的示例分别类似于“Z123456789.com.example.app-group”和“DG29478A379Q6483R9214.HolstFirstAppSuite”。 (哇,这是最后一个超级奇怪的团队ID还是什么?)
因此,如果出现这种不一致的情况,我该如何才能使应用程序组ID生效?我应该进入配置门户“group.TEAM-ID.com.example.blah”吗?我应该在源代码字符串中使用相同的字符串,还是省略“组”。部分就像许多代码示例?或者说文档错了,从不需要团队ID?
上下文...我一直在尝试更新iOS cocoapod的测试应用,这样我就可以看到扩展名< - >应用程序通信在行动。将应用程序ID和组ID更新为我的控件中的一个,并且当使用类似于项目的原始组ID的组ID时,例如“group.com.mycompany.thingie”,我看到containerURLForSecurityApplicationGroupIdentifier:
什么都不做,只返回nil并nothing else修复了它。
更新:(为了清楚了解这是如何告诉我这个Q获得了很多点击而添加了这个)事实证明这些东西比我原先想象的更宽容,因为nil
结果结果证明(主要是?)我在做什么。看到答案&它的评论主题。我没有检查是否有文件和&例子还清楚。
答案 0 :(得分:8)
在https://developer.apple.com里面"证书,标识符&简档"当你去" App Groups"部分并首先生成您的应用程序组,所需的只是强制执行的group.com.companyname.appname
只要com.companyname.appname与您在一般情况下设置的目标的分发包标识符相匹配,您就应该能够转到"功能"选项卡,打开"应用程序组"单击刷新符号,您在Provisioning Portal中创建的组应该出现在那里," group.com.companyname.appname"您可以选择将其关闭,然后将在权利方面出错。点击"修复问题"应该自动解决它。
现在,如果您导航到您的权利文件,您会注意到" com.apple.security.applications-groups"将有一个项目,它将被设置为完全相同的" group.com.companyname.appname"值。
我已经在设备上进行了测试,但还没有任何问题。这并不能解释文档中的不一致,但我可以保证这是有效的。
答案 1 :(得分:8)
在提交我的应用程序的macOS Sierra版本时,我被iOS和macOS之间的不一致所困扰。
group.better.fyi适用于iOS提交,但在macOS提交期间会导致以下错误(否则运行完美,没有任何警告或错误):
ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '[group.better.fyi]' for key 'com.apple.security.application-groups' in 'ind.ie.Better-Mac.pkg/Payload/Better.app/Contents/PlugIns/Blocker-Mac.appex/Contents/MacOS/Blocker-Mac' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' ."
在应用程序组下的功能选项卡中用$(TeamIdentifierPrefix)better.fyi
替换它解决了问题。
当然,这会在iOS和Mac应用程序之间造成不一致。
答案 2 :(得分:1)
tl;dr 版本:https://stackoverflow.com/a/66647419/15809
但如果您想了解这一切背后的所有细节,请参见下文。
在门户中,创建的所有应用组 ID 必须以 group.
开头;门户网站实际上会强制执行此操作,因此甚至无法在没有该前缀的情况下在那里注册群组。
如果随后在门户中的应用 ID 上设置了应用组 ID,并为该应用 ID 创建了 iOS 配置文件,则该应用组将完全按照注册的方式嵌入到配置文件中。看看这样的配置文件,你会在那里找到应用组 ID。
如果 iOS 应用程序在其 codesign 授权文件中具有应用组 ID,则 codesign 将确保在配置文件中也可以找到来自授权的组 ID,否则将拒绝对应用程序进行签名。因此,配置文件会将这些应用组的使用列入白名单。
当您在 Xcode 中的功能部分为应用程序配置应用程序组 ID 时,Xcode 会为您将该 ID 放入代码设计授权文件中。此处为 iOS 应用配置的应用组必须与门户中注册的应用组 ID 完全匹配。
但是对于 macOS,情况完全不同!
如果您将应用组 ID 添加到门户中的应用 ID,这不会影响为该应用 ID 创建的 macOS 配置文件。自己看看;在生成的配置文件中找不到应用程序组 ID!因此,在 macOS 上,配置文件不会将任何应用程序组的使用列入白名单。您可以将任何应用程序组 ID 放入您的权利文件中,这将始终签名,因为 codesign 不在乎。 Codesign 甚至不关心您的应用组 ID 是否以您的团队 ID 为前缀(或者至少它过去没有使用过,也许现在是这样)。
与 iOS 不同,macOS 上的应用组 ID 的唯一性不是由门户强制执行的,而是由 Apple 要求您的应用组 ID 以您的团队 ID 开头这一事实强制执行,因此跨团队的唯一性得到保证并强制执行您自己团队中的独特性是您自己的任务。
实际上,您根本不需要在门户中为 macOS 应用注册应用组 ID。只需将您想要的应用程序组 ID 放入您的 Xcode 项目功能中,从而放入您的权利文件中就足够了。许多人认为他们在门户中注册 group.TEAM_ID.<whatever>
时已经正确注册了他们的 macOS 应用程序组,并且一些魔法使该组在 Mac 上无需 group.
前缀即可工作,但事实并非如此。他们刚刚注册了一个同名的 iOS 群组,TEAM.<whatever>
在 Mac 上运行的原因是因为该群组不需要在门户中注册。
现在有些读者会说:等一下;如果我可以将任何应用程序组 ID 放入我的权利文件中并且它始终会签名,那么实际上是谁强制它以我的团队 ID 为前缀? Mac 应用商店。 Mac App Store 不允许您发布应用组 ID 未以发布者团队 ID 为前缀的应用。如果您尝试,上传将失败。
您可能想知道:对于在应用商店之外分发的应用,谁强制应用组以您的团队 ID 为前缀?没有人。但是,在应用程序商店之外分发的应用程序可以声称是任何应用程序组的成员,甚至是来自不同开发团队的应用程序,那么这如何安全呢?不是。在应用程序商店之外分发的应用程序甚至不必经过沙盒处理,如果它们没有经过沙盒处理,它们就可以访问您的整个磁盘,包括所有应用程序的所有应用程序组文件夹,那么如果错误声明,安全性将如何降低成为应用群组的成员?
如果出于安全原因希望限制自己在应用商店之外分发的应用可能会被沙盒化,但即使他们选择加入,他们也可以根据需要或希望自由地在自己的沙盒中戳出尽可能多的漏洞,因为与通过应用商店分发时,没有任何审查可以确保他们只戳必要和合理的漏洞。
在 iOS 上,所有应用程序总是经过沙盒处理并通过 App Store 分发,因此这个问题甚至不会出现。
钥匙串项目共享怎么样?通过应用程序组共享钥匙串项目仅适用于 iOS,不适用于 macOS;正是因为这个原因!在 Mac 上会不安全。在 macOS 上,仅与钥匙串访问组共享有效,并且那些在配置文件中,也在 macOS 配置文件中,对于这些代码,代码将始终强制配置文件在签署任何内容之前将它们列入白名单。
您希望 Apple 直接确认所有这些吗?当然,以下是我们最著名的 Apple 技术支持大师 Quinn 提供的参考:
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022