Pie*_*ton 13 macos cocoa cocoa-touch ios appstore-sandbox
在Provisioning Portal中创建应用程序组ID时(或现在称为其中的任何内容),它会显示"为应用程序组输入唯一标识符,从字符串'group'开始",并且似乎在输入字段中强制执行该操作.此外,许多示例代码使用app group id字符串,如"group.com.company.blah".
但是,我看到的最终部分链接整个文档, App Sandbox设计指南> App Sandbox In Depth>容器目录和文件系统访问>应用程序组容器目录和权利密钥Rerefence>启用App Sandbox>添加应用程序到与之相反的应用程序组明确指出"必须从您的开发团队ID开始,然后是一段时间".
这些部分中给出的示例分别类似于"Z123456789.com.example.app-group"和"DG29478A379Q6483R9214.HolstFirstAppSuite".(哇,这是最后一个超级奇怪的团队ID还是什么？)
因此,如果出现这种不一致的情况,我该如何才能使应用程序组ID生效？我应该进入配置门户"group.TEAM-ID.com.example.blah"吗？我应该在源代码字符串中使用相同的字符串,还是省略"组".部分就像许多代码示例？或者文档是错误的,并且从不需要团队ID？
上下文...我一直在尝试更新iOS cocoapod的测试应用程序,以便我可以看到扩展< - >应用程序通信正在运行.将应用程序ID和组ID更新为我的控件中的一个,并且当使用类似于项目的原始组ID时,例如"group.com.mycompany.thingie",我看到containerURLForSecurityApplicationGroupIdentifier:什么都没做,只返回nil并且没有其他任何修复它.
更新:( 为了清楚地看到SO如何通知我这个Q获得了很多点击量,这个添加了这一点)事实证明这个东西比我原先想象的更宽容,因为nil结果证明(主要是？)我在做什么.查看答案及其评论主题.我还没有检查文档和示例是否更清晰.
小智 8
在"证书,标识符和配置文件"中的https://developer.apple.com上,当您转到"应用程序组"部分并首先生成应用程序组时,所需的只是强制执行的group.com.companyname.appname
只要com.companyname.appname与您在一般情况下设置的目标的分发包标识符匹配,您就应该可以转到"功能"选项卡,打开"应用程序组",单击刷新符号,然后将组分组刚刚在Provisioning Portal中创建的应该出现在那里,因为"group.com.companyname.appname"您可以选择将其检查出来,然后将出现权限错误.单击"修复问题"应自动解决该问题.
现在,如果您导航到权利文件,您会注意到"com.apple.security.applications-groups"将有一个项目,它将被设置为完全相同的"group.com.companyname.appname"值.
我已经在设备上进行了测试,但还没有任何问题.这并不能解释文档中的不一致,但我可以保证这是有效的.
在提交我的应用程序的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应用程序之间造成不一致.
tl;dr 版本：/sf/answers/4665319361/
但如果您想了解这一切背后的所有细节，请参阅下文。
在门户中，创建的所有应用程序组 ID 必须以group.;开头 门户网站实际上会强制执行这一点，因此如果没有该前缀，甚至无法在那里注册组。
如果随后在门户中的应用程序 ID 上设置应用程序组 ID，并为该应用程序 ID 创建 iOS 配置文件，则应用程序组将按照注册时的方式嵌入到配置文件中。查看这样的配置文件，您会在那里找到应用程序组 ID。
如果 iOS 应用程序在其 codesign 权利文件中包含应用程序组 ID，则 codesign 将确保在配置文件中也找到权利中的组 ID，否则它将拒绝对应用程序进行签名。因此，配置配置文件将这些应用程序组的使用列入白名单。
当您在 Xcode 的功能部分为应用程序配置应用程序组 ID 时，Xcode 会将 ID 放入 codesign 权利文件中。为 iOS 应用程序配置的应用程序组必须与门户中注册的应用程序组 ID 完全匹配。
但对于 macOS 来说，情况就完全不同了！
如果您将应用程序组 ID 添加到门户中的应用程序 ID，这不会影响为该应用程序 ID 创建的 macOS 配置文件。你自己看看；在生成的配置文件中找不到应用程序组 ID！因此，在 macOS 上，配置配置文件不会将任何应用程序组的使用列入白名单。您可以将任何应用程序组 ID 放入您的权利文件中，这将始终进行签名，因为协同设计并不关心。Codesign 甚至不关心您的应用程序组 ID 是否以您的团队 ID 为前缀（或者至少过去不使用，也许从今天开始）。
与 iOS 不同，macOS 上应用程序组 ID 的唯一性不是由门户强制执行的，而是由 Apple 要求您的应用程序组 ID 以团队 ID 开头这一事实强制执行的，因此可以保证跨团队的唯一性，并在您的应用程序组 ID 中强制执行唯一性。自己的团队是你自己的任务。
实际上，您根本不需要在门户中为 macOS 应用程序注册应用程序组 ID。只需将所需的应用程序组 ID 放入 Xcode 项目功能中，然后放入权利文件中就足够了。group.TEAM_ID.<whatever>许多人认为他们在门户中注册时已经正确注册了 macOS 应用程序组，并且某些魔法使该组group.在 Mac 上无需前缀即可工作，但事实并非如此。他们只是注册了一个同名的 iOS 组，之所以能TEAM.<whatever>在 Mac 上运行，是因为该组不需要在门户中注册。
现在有些读者会说：等一下；如果我可以将任何应用程序组 ID 放入我的权利文件中并且它始终会签名，那么谁实际上强制它以我的团队 ID 为前缀？Mac 应用商店。Mac App Store 不允许您发布应用程序组 ID 不以发布者团队 ID 为前缀的应用程序。如果您尝试，上传将会失败。
您可能想知道：对于在 App Store 之外分发的应用程序，谁强制要求应用程序组以您的团队 ID 为前缀？没有人。但是，在应用程序商店之外分发的应用程序可以声称自己是任何应用程序组的成员，甚至是来自不同开发团队的应用程序组的成员，那么这如何保证安全呢？事实并非如此。在 App Store 之外分发的应用程序甚至不必进行沙盒处理，如果它们没有进行沙盒处理，它们就可以访问您的整个磁盘，包括所有应用程序的所有应用程序组文件夹，因此，如果错误声明，这会如何变得不那么安全？成为应用程序组的成员？
如果出于安全原因希望限制自己，那么在 App Store 之外分发的应用程序可能会被沙箱化，但即使他们选择这样做，他们也可以根据需要或愿望在自己的沙箱中随意戳出尽可能多的漏洞，因为与通过分发时不同在 App Store 中，没有任何审查可以确保它们只戳必要且合理的漏洞。
在 iOS 上，所有应用程序始终都经过沙箱处理并通过 App Store 分发，因此根本不会出现这个问题。
钥匙串物品共享怎么样？通过应用程序组共享钥匙串项目仅适用于 iOS，不适用于 macOS；正是因为这个原因！在 Mac 上这会不安全。在 macOS 上，仅与钥匙串访问组共享才有效，并且这些共享位于配置文件中，也在 macOS 配置文件中，并且对于这些代码设计，将始终强制配置文件在签署任何内容之前将它们列入白名单。
您想让 Apple 直接确认所有这些内容吗？当然，这是我们最著名的 Apple 技术支持大师 Quinn 提供的参考：
https://developer.apple.com/forums/thread/133677 ?answerId=422887022#422887022
| 归档时间： |
|
| 查看次数： |
4626 次 |
| 最近记录： |