iOS 11：DeviceCheck API

---

快速说明-我将来所有的帖子都将发布在我的专用网站上，并且此出版物不再更新。 谢谢阅读！

---

每个WWDC，总是会有晦涩的API进入每年的新玩具“单词泡沫”幻灯片，供开发人员使用。 微弱地坐在那里，这是有理由的，苹果公司认为它是有用的补充，只有少数几个会使用，而不会很多。

DeviceCheck适合该帐单，然后再适用。 您可能会认为Cupertino＆Friends ™的必要性，他们不得不做出或面对这样一个现实，即工程师会找到另一种方法来处理X或Y，从而导致可耻的目的。 因为开发人员不会像以往那样做任何可疑的事情。

因此，DeviceCheck有点像大多数开发人员出于完全正当的商业原因想要做某事时发生的事情，但是实际上并没有任何好的方法。 这是一个奇怪的小API，这是我们本周讨论的主题。

那么，这是什么？

TL; DR仅此而已：这是Apple认可的有保证的方式，可以在保持绝对用户隐私的同时，将您的应用标识为在有效的Apple设备上运行。

我想那不是新闻中最有趣的。 这里真正的讨论在于事物的为什么部分。 在这种情况下，频谱的使用范围可能包括从切换某个设备上的促销优惠，将购买链接到帐户或为欺诈活动审核设备。 例如，会议室中谁在此使用两个不同的用户名或个人资料来扩展某种免费试用？

…

…..

……..

♂‍♂️

就是这样 我们只是在帮助一个人，特别是为任何给定的iOS（或tvOS）设备关联某个给定的状态。

为了使您的创意源源不断，请考虑已发布了两个应用程序。 如果他们打开App One，则可以将设备分配为状态01；当他们打开App Two时，您可以查询状态，因为状态将以相同的方式保留，然后解锁一些内容，折扣或奖励。

它是与应用程序无关的API，因此在场合需要时可以充分利用它。 但是，也请注意，这是否会对您构成设计约束。 再说一次，我们谈论的是每个设备两位，而不是每个应用程序两位。

那么它是怎样工作的？

API

我一直很欣赏“直截了当”的API类型，而这正是我们所能获得的。 该设置允许开发人员为每台设备存储两位信息（以及时间戳）。 因此，与其偷窥苹果希望让您闭门识别设备的几扇门，您还可以拿回一点点并完成该操作：

 让curDevice = DCDevice.currentif curDevice.isSupported
 {
     curDevice.generateToken（completionHandler：{（数据，错误）在
        如果让tokenData =数据
         {
             print（“接收到的令牌\（tokenData）”）
         }
        其他
         {
            打印（“命中错误：\（错误！.localizedDescription）”）
         }
     }）
 } 

请注意，模拟器不会通过isSupported，因此，如果您要对其进行测试，我想无论如何都要做我们应该做的事情，并使用真实的东西📱。

有了该代码，您就可以进行以下操作：

• 00
• 01
• 10
• 11

设置该信息后，该信息将一直有效并由Apple存储，直到您作为开发人员手动将其重置或更新为止。 这意味着您不必通过棘手的事情编写代码，例如重新安装，核对所有内容和设置或直接删除。 还值得注意的是，每个团队ID的这些值都是唯一的。

另外，请注意，与大多数令牌一样，它仅供一次性使用。 正如您将在稍后看到的那样，您很可能在应用程序外部和服务器上使用此令牌。 如果您需要重试一个请求，它将保持足够长的有效时间，但是大苹果公司建议使用相同的方法来生成另一个请求。

近距离观察

您可能正在看以前的代码示例，并且想知道这对我们有什么帮助。 如何分配位？ 您如何设置状态？ 到目前为止，我们正在做的只是获得令牌。 您可能期望过这样的事情：

 让curDevice = DCDevice.current
 curDevice.setFirstBitState（as：true）// or curDevice.secondBitState（）== true
 {
     // 做点什么
 } 

这是一个公平的问题，这是因为客户端API（iOS或tvOS）仅处理一半的事务。 在iOS上，我们获得了一个临时令牌，该令牌将发送到我们自己的服务器。 这可以验证真实性，然后我们可以设置位状态或对其进行查询，然后向Apple发送请求。 然后，Apple向我们提供了我们所追求的状态。

看起来像这样：

1. 客户端使用DeviceCheck获取令牌
2. 它发送到我们的服务器，我们决定状态
3. 我们将令牌传递给Apple，然后完成

然后稍后查询：

1. 客户端使用DeviceCheck获取令牌
2. 您的服务器使用Apple查询设备的状态
3. 得到响应，您的应用将采取适当的措施

这听起来并不那么费劲。 一个简单的POST并将您的身份验证密钥包装为JSON Web令牌，可以带您到那里。 查询位状态的请求仅需要包含JSON负载，如下所示：

{ "device_token" : "anAmazingUniqueToken" "timestamp" : 0934423486434, "transaction_id" : "you come up with this" } 

然后苹果会回应：

 { "bit0" : false "bit1" : true, "last_update_time" : "2017-10" } 

回到另一种方式，如果需要更新它–有效负载是完全相同的，除了您包括一个或两个要更新的位：

 { "device_token" : "anAmazingUniqueToken" "transaction_id" : "you come up with this", "timestamp" : 0934423486434, "bit0" : false, "bit1" : true } 

在说完所有这些之后，我假设您已经知道发送Web请求必须采取的其他后勤陷阱。 例如，遵循Base 64 URL编码的JSON Web令牌格式，并确保您的身份验证密钥采用ES256算法。 否则，您将没有任何有用的信息来满足状态要求，而是得到了一个不错的BAD_AUTHENTICATION_TOKEN http错误🙈。

有关如何设置这些请求，使用哪些数据类型甚至使用curl的一些示例请求的更多信息，请务必点击文档。

成为一名优秀的设备检查公民

与任何API一样，处理事情有对与错的方法。 使用DeviceCheck，虽然看起来很简单，但有几种选择方案可以识别。

首先，请回想一下苹果在查询过程中为我们提供的时间戳：

 { "bit0" : false "bit1" : true, "last_update_time" : "2017-10" } 

该更新时间将四舍五入到最接近的月份。 这可以帮助您解决由于设备出售给其他人而引起的一些问题。 例如，如果位状态说他们做了某件事，他们应该只做一次，但是自从他们尝试过以来已经一年了–将这一事实与其他业务逻辑相结合，以避免将新客户拒之门外。

这直接将我们引至Apple建议的下一个技巧，这是帮助解决这些特定问题的补充资料。 也就是说，它应该与您的业务逻辑配对。 获取位状态是一个很好的开始，当然会受到帮助，但是将其与逻辑检查配对可以帮助您确保不会阻碍新用户。

还提到这应该不会对您的用户界面造成太大影响。 我认为这是很明显的，但是再增加一点也不会造成伤害。 我们大多数人都有几种了解何时引入您的应用程序的“首次运行”模式的方法。 查询一个位状态，该位状态至少需要跨越导线三跳。

最后，Apple给我们这个API是有原因的。 在关于该主题的WWDC聊天中，他们直截了当地说他们将继续彻底删除熵的来源，或者至少确保它们在用户的控制之下。 阅读：“如果您滥用我们的生态系统来标记手机，我们将找到您并消除您的方法。”

包起来

UDID查询已结束。 通过IP地址链接回链接很容易破解。 因此，无论是否有恶意，现在唯一标识iOS设备的行为在iOS 11中都具有一流的支持。我赞扬Apple决定采用安全实用的方法来实现这一目标。 因为外面某个地方有一个具有业务需求的开发人员，需要做这样的事情。

现在，他们可以。 而且他们也不必做任何时髦的舞蹈。

直到下次time️。

---

乔丹·摩根（@ JordanMorgan10）| 推特

Jordan Morgan（@ JordanMorgan10）的最新推文。 iOS位于@buffer。 在自己的时间上处理支出堆栈…

www.twitter.com

 如果您喜欢本周的帖子，请随时继续并进行NSRecommend（this，where：below）;