与人们的想法相反(一个例子:使用 APPLE 的 APP TRANSPORT SECURITY)NSAllowsArbitraryLoads
不能作为在黑名单/白名单模式之间切换的标志,至少它不能很好地与 Charles 配合使用:
黑名单方法(在 IOS 9.0 中不适用于我 - Charles 无法识别来自/到暂存主机的流量):
示例 B:适用于所有人的 ATS,但有一些例外
如果您希望您的所有域都可以使用 ATS,除了一些您知道无法使用的域,您可以指定不应使用 ATS 的例外情况,同时选择所有其他流量。对于这种情况,您需要使用 NSExceptionDomains 指定您希望覆盖 ATS 的默认设置的域。
白名单方法(可行,但不是真正的好方法):如果NSAllowsArbitraryLoads
设置为,YES
则应用程序传输安全功能对所有域禁用,除了NSExceptionDomains
.
示例 C:禁用 ATS,但有一些例外
相反,您可能只希望 ATS 在您明确知道可以支持它的域上工作。例如,如果您开发了一个 Twitter 客户端,您可能想要加载无数的 URL,这些 URL 可能无法支持 ATS,尽管您希望登录调用和其他对 Twitter 的请求以使用 ATS。在这种情况下,您可以默认禁用 ATS,然后指定您希望使用 ATS 的 URL。
此处描述的另一种方法:This One Weird Trick Makes Developing iOS Apps against a Local Server Way Easier建议添加“运行脚本构建阶段”,该阶段使用 PlistBuddy 即时修补应用程序的 plist 文件。这是他们的示例,当开发人员在其本地计算机上处理服务器时(当然也可以是登台主机),使应用程序不使用 ATS:
/usr/libexec/PlistBuddy -c "Add :NSAppTransportSecurity:NSExceptionDomains:$LOCAL_NETWORK_NAME:NSIncludesSubdomains bool true" $INFO_PLIST
/usr/libexec/PlistBuddy -c "Add :NSAppTransportSecurity:NSExceptionDomains:$LOCAL_NETWORK_NAME:NSThirdPartyExceptionAllowsInsecureHTTPLoads bool true" $INFO_PLIST
IMO,修补 Plist 是有条件地为暂存主机禁用 ATS 的更好方法,而不是使用上述白名单方法,因此我们将坚持使用 PlistBuddy。