iOS/OSX应用程序组ID,以“group.”或“team-id."开头,

ltqd579y  于 12个月前  发布在  iOS
关注(0)|答案(3)|浏览(150)

当在Provisioning Portal(或现在的任何名称)中创建应用程序组ID时,它会说“输入应用程序组的唯一标识符,以字符串'group'开头”,并且似乎在输入字段中强制执行。此外,许多示例代码使用应用程序组ID字符串,如“group.com.company.blah”。
然而,我在整个文档中看到的链接的权威部分,应用沙箱设计指南>应用沙箱深度>容器目录和文件系统访问>应用程序组容器目录和权利密钥参考>启用应用沙箱>将应用程序添加到应用程序组,直接与此相矛盾,明确指出“必须以您的开发团队ID开始开始,后跟一个句号”。
这些部分中给出的示例分别类似于“Z123456789.com.example.app-group”和“DG29478A379Q6483R9214.HolstFirstAppSuite”。* (哇,最后一个是超级奇怪的团队ID还是什么?)*
那么,在这种不一致的情况下,我该怎么做才能让应用程序组ID正常工作呢?我应该在配置门户中输入“group.TEAM-ID.com.example.blah”吗?我应该在源代码字符串中使用相同的字符串,还是像许多代码示例那样省略“group.”部分?或者是文档错误,团队ID永远不需要?
我一直在尝试更新iOS cocoapod的测试应用程序,这样我就可以看到扩展<->应用程序的通信。在我的控件中将应用程序ID和组ID更新为1之后,当使用与项目原始ID类似的组ID时,如“group.com.mycompany.thingie”,我看到containerURLForSecurityApplicationGroupIdentifier:除了返回nil外什么也没做,nothing else已经修复了它。
更新:(为了清楚起见,添加了这个,看看SO是如何告诉我这个Q得到了很多点击) 事实证明,这个东西比我最初想象的更宽容,因为nil的结果(大部分?)我做的。看到答案和它的评论线程。我还没有检查文档和示例是否更清晰。

ecr0jaav

ecr0jaav1#

https://developer.apple.com上,在“Certificates,Identifiers & Profiles”(证书、标识符和配置文件)中,当您转到“App Groups”(应用程序组)部分并首先生成您的App Group(应用程序组)时,所需的全部内容是强制组.com.companyname.appname
只要com.companyname.appname与您在常规下设置的目标捆绑包标识符相匹配,您就应该能够转到“功能”选项卡,打开“应用程序组”,单击刷新符号,您刚刚在Provisioning Portal中创建的组应该出现在那里,作为“group.com.companyname.appname”,您可以选择将其选中,然后将出现权利错误。点击“修复问题”应该会自动解决它。
现在,如果你导航到你的权利文件,你会注意到“com.apple.security. applications-groups”将有一个项目,它将被设置为完全相同的“group.com.companyname.appname”值。
我已经在设备上测试过了,还没有问题。这并不能解释文档中的不一致性,但我可以保证这是有效的。

tf7tbtn2

tf7tbtn22#

在提交我的应用程序的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应用程序之间的不一致。

vnjpjtjt

vnjpjtjt3#

tl;dr版本:https://stackoverflow.com/a/66647419/15809
但如果你想知道这一切背后的所有细节,请参阅下文。

iOS

在门户中,所有创建的应用组ID必须以group.开头;门户网站实际上会强制执行这一点,所以甚至不可能在那里注册一个没有该前缀的组。
如果随后在门户中的应用ID上设置应用组ID,并为该应用ID创建iOS预配配置文件,则应用组将完全按照注册时的状态嵌入配置文件中。看看这样的配置文件,你会发现应用程序组ID在那里。
如果iOS应用在其codesign授权文件中包含应用组ID,codesign将确保在配置文件中也能找到授权中的组ID,否则将拒绝对应用进行签名。因此,供应配置文件将这些应用组的使用列入白名单。
当您在Xcode的capabilities部分为应用配置应用组ID时,Xcode会将ID放入codesign授权文件中。在此为iOS应用配置的应用组必须与门户中注册的应用组ID完全匹配。

macOS

但对于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 App Store Mac App Store不允许您发布应用组ID未以发布者的团队ID为前缀的应用。如果您尝试,上传将失败。

应用群组及安全

你可能会想:对于在App Store之外分发的应用程序,谁强制要求应用程序组以您的团队ID为前缀?但是在应用商店之外发布的应用程序可以声称是任何应用程序组的成员,甚至是来自不同开发团队的应用程序组,那么这如何安全呢?在App Store之外发布的应用甚至不必进行沙箱化,如果它们没有进行沙箱化,它们就可以访问您的整个磁盘,包括所有应用的所有应用组文件夹,因此,如果错误地声称自己是应用组的成员,这怎么会降低安全性呢?
在App Store之外分发的应用程序可能会被沙箱化,如果他们希望出于安全原因限制自己,但即使他们选择这样做,他们也可以根据需要或愿望自由地在自己的沙箱中戳出尽可能多的漏洞,因为与通过App Store分发时不同,没有审查可以确保他们只戳出必要和合理的漏洞。
在iOS上,所有的应用程序都是沙箱化的,并通过App Store分发,所以这个问题甚至不会出现。

应用群组和密钥链共享

钥匙链项目共享怎么样?通过应用程序组共享钥匙串项目仅适用于iOS,而不是macOS;就是因为这个原因在Mac上是不安全的。在macOS上,只有与密钥链访问组共享才有效,这些都在配置文件中,也在macOS配置文件中,对于那些codesign将始终强制配置文件在签署任何内容之前将其列入白名单。

来自苹果的参考

你想让苹果直接确认这一切吗?当然,这是我们最著名的苹果技术支持大师Quinn提供的参考:
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022

相关问题