iCloud API(v1)

更新

本文档介绍了Reincubate的传统iCloud API的使用。

概观

API - 特别是Feed - 提供了许多实质性好处:

  • 易于集成 。 API可以轻松地与任何级别的开发团队一起使用,并且无需客户就iCloud / CloudKit存储或任何第三方应用程序获得任何高度专业知识。

    这个好处并不容易被夸大:开发和维护iCloud接口的复杂性非常大,而且最重要的是需要支持核心iOS数据和应用程序文件的多种数据格式。 iOS不仅使用不同的数据格式,而且每个应用程序(例如,WhatsApp)都使用一组数据格式和结构,这些格式和结构可以通过应用程序更新逐周更改。

    API支持所有“困难”功能:iOS 9,iOS 10,CloudKit,iCloud 8 + 9合并,2SV / 2FA,部分快照,令牌化,A9和A9X。

  • 未来的证明 。 Reincubate致力于维持对当代和过去的iCloud和iOS数据格式的支持,并在此领域拥有良好的记录:

    • 第一个支持iOS数据访问(2008)
    • 第一个支持加密的iOS数据访问(2009)
    • 1号支持iCloud数据提取(2011)
    • 第一个和仅支持iCloud / CloudKit iOS 9数据访问的API(2015)
  • 支持和获得无与伦比的专业知识 。由于公司作为应用数据公司的重点和定位,Reincubate的团队在该领域拥有无与伦比的经验和知识。这种体验对于探索新应用和用例的客户尤其有用。

    JSON提要的用户能够利用Reincubate的专有技术来提取和取消应用数据,从而使得结果数据更准确。

  • 开箱即用的应用程序支持 。除了核心的iOS数据类型- 所有这些都在所有的iOS版本上的所有设备支持-该API具有模块,支持几十种第三方应用程序。一些较受欢迎的支持应用程序包括WhatsApp,Viber,Kik,WeChat,Line,SnapChat,Facebook Messenger和Skype。

  • 开箱即用的开发者平台支持 。 API具有多种语言的开源客户端实现,包括Python.NET / C#JavaScript

  • 速度和可扩展性 。 Reincubate iCloud API平台是按比例构建的,JSON Feed系统比原始文件访问更快,扩展性更好。

  • 丰富的Feed自定义选项 。可以轻松定制订阅源部署的订阅源平台。示例包括protobuf格式提要和消息传递应用程序附件的聚合。

  • 信任 。 Reincubate受到全球安全,LEA和政府用户的信赖。该公司遵守严格的英国数据保护法规,并符合欧盟和美国安全港法规。

入门

有兴趣的人可以联系企业团队以获取API密钥。但是,在所有示例客户端实现中都提供了测试密钥。

安装示例Python客户端

可以使用单个命令安装Python iCloud库。要获取旧版库,必须安装最新的1.*版本。

$ pip install ricloud==1.*

该客户端的源代码可以在ricloud-py下的GitHub上找到。

安装示例JavaScript客户端

可以使用单个命令安装JavaScript iCloud库。要获取旧版库,必须安装最新的1.*版本。

$ npm install ricloud==1.*

该客户端的源代码可以在ricloud-js下的GitHub上找到。

安装示例.NET / C#客户端

可以使用单个命令安装C#iCloud库。要获取旧版库,必须安装最新的1.*版本。

$ nuget install ricloud==1.*

该客户端的源代码可以在ricitoud-csharp下的GitHub上找到。

组态

每个客户端实现都带有自己的捆绑文档集,以及一个示例脚本,说明如何使用它。配置通常仅限于指定用于API的身份验证的userkey值。

使用API

用户可能需要使用API执行三个核心操作。

  • 身份验证和枚举: sign-inperform-2fa-challengesubmit-2fa-challenge
  • Feed数据访问: download-data
  • 原始文件访问: download-file

本节中的示例以curl格式给出。

在对API发出的所有请求中,必须告知curl遵循带有-L参数的重定向。用户的API凭证也必须使用--user "USER:KEY"进行设置,自定义API版本标头也必须设置, - --header "Accept: application/vnd.icloud-api.v1" 。因此,这些示例中的所有curl调用必须以:

curl -L
     -v
     -X POST
     --user "USER:KEY"
     --header "Accept: application/vnd.icloud-api.v1"

请注意,还指定了-X POST选项,因为所有请求都是通过POST 。由于此调用不会更改,因此下面将其称为CURL_CALL

作为一般准则,所有请求(错误除外)都返回一个标识当前会话的session_key字段。如果未发送,则应使用sign-in请求生成新会话。应始终如一地使用session_key值。

1.认证,2FA / 2SV以及设备和数据列表的检索

要以具有双因素身份验证或在其帐户上启用两步验证的用户身份sign-in必须使用sign-in方法。

CURL_CALL --data-urlencode "email=ICLOUD_EMAIL"
          --data-urlencode "password=ICLOUD_PASSWORD"
          https://api.icloudextractor.com/c/sign-in/

要访问的iCloud帐户的emailpassword作为参数传递,使用--data-urlencode确保控制字符(如@被转义。

使用无效的API密钥对登录

如果用户使用无效的密钥对请求API,则不会返回403以外的数据。

HTTP/1.1 403 FORBIDDEN

登录最终用户尚未接受iCloud T&C的帐户

如果用户尝试登录尚未接受更新的一组iCloud条款和条件的iCloud帐户。

HTTP/1.1 400 BAD REQUEST
{
 "error": "terms-of-service-update",
 "message": "User hasn't agreed to Apple's Terms of Service."
}

使用错误的iCloud凭据登录

如果用户尝试使用错误的iCloud凭据登录,则将返回403以及错误消息。

HTTP/1.1 403 FORBIDDEN
{"message": "Unsuccessful login attempt: renate@reincubate.com",
 "error": "unable-to-login"}

登录最终用户尚未验证的帐户

如果用户尝试登录未由用户验证主电子邮件的iCloud帐户。

HTTP/1.1 400 BAD REQUEST
{
 "error": "unverified-account",
 "message": "User's primary email hasn't been verified."
}

在没有2FA / 2SV的情况下登录

只需一个请求即可使用非2FA帐户登录。

HTTP/1.1 200 OK
{"devices":
 {"7c7fba66680ef796b916b067077cc246adacf01d": {
    "ios_version":   "9.0.1",
    "colour":        "#e4e7e8",
    "device_name":   "Renate's iPhone",
    "latest-backup": "2015-11-17 16:46:39.000000",
    "model":         "N71mAP",
    "serial":        "D56DF63DYTBG",
    "name":          "iPhone 6s"},
 "8e281be6657d4523710d96341b6f86ba89b56df7": {
    "ios_version":   "9.1",
    "colour":        "#e1e4e3",
    "device_name":    "Renate's iPad",
    "latest-backup": "2015-11-13 19:35:52.000000",
    "model":         "J98aAP",
    "serial":        "E32VR64AFXVF",
    "name":          "iPad Pro"},
 },
 "key": "b3d11d6c-52c0-4754-a971-8f305047a0f6",
 "auth_token": "N28GZaKvTXAGrhBIx3UgRGml47oPVCCq4tqM5huyCKo2r7h2HfMtyBsZVc3SS2sh5h3I"}
}

使用2SV / 2FA登录

如果帐户使用双因素身份验证进行保护,则sign-in请求将返回一条错误消息,指出two-factor authentication is enabled on this accounttwo-factor authentication is enabled on this account ,即session_key ,如果是2SV,则还会返回trustedDevices列表。

  • 2SV
HTTP/1.1 409 CONFLICT
{"message": "This account has Two Step Verification enabled, please select a device to challenge.",
 "data": {
  "trustedDevices": ["********12", "Renate's iPhone - iPhone 6s"],
  "key": "b3d11d6c-52c0-4726-a971-8f305047a0f6"
 },
 "error": "2fa-required"
}

对于2SV,下一步是发出2SV询问码的一个trustedDevices 。为此,请求perform-2fa-challenge

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode "challenge=DEVICE_TO_CHALLENGE"
          https://api.icloudextractor.com/c/perform-2fa-challenge/

发送的参数是challenge ,必须包含在trustedDevices上列出的项目,以及session_key ,它将与返回的sign-in请求相同。

  • 2FA

在2FA的情况下,不同之处在于请求将返回空的trustedDevices列表。

HTTP/1.1 409 CONFLICT
{"message": "This account has Two Factor authentication enabled, all devices will be challenged.",
 "data": {
  "trustedDevices": ["Challenge all 2FA devices"],
  "key": "b3d11d6c-52c0-4726-a971-8f305047a0f6"
 },
 "error": "2fa-required"
}

对于2FA,我们无法选择哪个设备受到质疑,因为每个受信任的设备都会自动受到质疑。为此,请求perform-2fa-challenge ,不带challenge参数。

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode
          https://api.icloudextractor.com/c/perform-2fa-challenge/

因此,对于2FA,发送的唯一参数是session_key ,它将与返回的sign-in请求相同。

使用坏设备挑战(2FA / 2SV)

如果用户使用无效device发出API请求,则不会返回超过500数据。

HTTP/1.1 500 INTERNAL SERVER ERROR

用坏钥匙挑战(2FA / 2SV)

如果用户使用无效key请求API,则它将返回带有验证消息的403

HTTP/1.1 400 BAD REQUEST
{"message": "Your iCloud session has expired. To continue, please sign in again.",
 "error": "key-invalid"}

挑战成功(2FA / 2SV)

HTTP/1.1 200 OK
{"message": "Challenge has been submitted."}

将挑战发送到用户的设备后,必须使用submit-2fa-challenge将发送的数据中继回API。

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode "code=2FA_CODE"
          https://api.icloudextractor.com/c/submit-2fa-challenge/

提交不良质询回复(2FA / 2SV)

HTTP/1.1 403 FORBIDDEN
{"message": "Incorrect code supplied for Two Factor Authentication.",
 "error": "invalid-2fa-code"}

提交正确的质询响应(2FA / 2SV)

HTTP/1.1 200 OK
{"message": "Challenge has been submitted."}

使用此请求,用户将完全通过身份验证,API会话将处于活动状态。

要完成登录过程并检索设备列表,请使用与第一个请求相同的emailpassword ,并使用通过2FA / 2SV身份验证过程使用的相同key ,提交sign-in的最终请求。

请注意,如果您的API密钥已启用auth_token ,则响应将仅包含auth_token条目。在这种情况下,我们建议您按照下面第4节中的说明提交最新的refresh-session请求,而不是将其提交到sign-in 。使用auth_token更加强大,因为它是Apple系统上已经建立的会话的指示器。

在新的API后端适配器上,您应该会看到不同的响应。这是由于2FA / 2SV过程流程的优化。

HTTP/1.1 200 OK
{"key": "b3d11d6c-52c0-4726-a971-8f305047a0f6",
"message": "Log-in successful",
"auth_token": "N28GZaKvTXAGrhBIx3UgRGml47oPVCCq4tqM5huyCKo2r7h2HfMtyBsZVc3SS2sh5h3I"
}

2.检索饲料数据: download-data

download-data方法用于访问feed数据。

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode "device=DEVICE_ID"
          --data-urlencode "mask=DATA_MASK"
          --data-urlencode "since=MIN_DATE"
          https://api.icloudextractor.com/c/download-data/

所需的该请求的参数是当前的session_key ,则device_id从登录响应的设备中的一个,并且所述data_mask ,这是一个OR全部进料模块标志的用户感兴趣的组合。还可以指定一个since从哪个日期开始寻找数据。

假设客户端的API密钥对所有这些模块都有效,则该方法将以JSON格式返回所请求的数据。

提交有效的Feed请求

如果传递给方法的值有效,它将返回HTTP响应正文中的订阅源内容。

HTTP/1.1 200 OK

提交缺少参数的Feed请求

如果缺少其中一个必需参数,该方法将返回错误的请求响应代码。

HTTP/1.1 400 BAD REQUEST
{"message": "mask missing from post.",
 "error": "invalid-request"
}

使用无效参数提交Feed请求

如果为任何参数提交了无效或格式错误的值,则该方法将返回错误的请求响应代码。

HTTP/1.1 400 BAD REQUEST
{"message": "Invalid since.",
 "error": "invalid-parameter"
}

示例Feed模块标志

对于download-data方法的mask参数,可以一起屏蔽以下模块标志。这不是一个详尽的清单。

  • 0000000000001消息
  • 0000000000002照片和视频
  • 0000000000004浏览器历史记录
  • 0000000000008通话记录
  • 0000000000016联系人
  • 0000000000032已安装的应用程序
  • 0000000000256位置(在线)
  • 0000000000512 WhatsApp消息
  • 0000000001024 Skype消息
  • 0000000002048日历
  • 0000000004096线路消息
  • 0000000008192 Kik消息
  • 0000000016384 Viber消息
  • 0000000032768 Facebook消息
  • 0000000065536微信留言
  • 0000000131072 Snapchat消息
  • 0000000262144文件列表
  • 0000000524288浏览器历史记录(直播)
  • 0000001048576 WhatsApp通话记录
  • 0000002097152 Viber通话记录
  • 0000004194304应用程序使用情况
  • 0000008388608备注
  • 0000033554432 HealthKit
  • 0000067108864 HealthKit仅限步骤
  • 0000134217728 Safari cookies
  • 0000268435456 Kik联系方式
  • 0000536870912 Viber联系人
  • 0001073741824 Viber对话
  • 0002147483648通话记录(直播)
  • 0004294967296地点
  • 0008589934592远足消息
  • 0017179869184 Snapchat的故事
  • 0034359738368语音邮件
  • 0068719476736录音
  • 0137438953472视频
  • 0274877906944照片和视频(直播)
  • 0549755813888 Tinder消息
  • 1099511627776链接Apple手表
  • 2199023255552远足帖子
  • 4398046511104联系人(在线)
  • 8796093022208帐户信息

例如,要请求消息,呼叫历史记录和浏览器历史记录的馈送,掩码将是1 + 4 + 8 = 13

JSON Feed格式

JSON提要旨在尽可能简单地解析。 Feed将返回单个响应中请求的所有数据类型。

模块标志中指定的每个feed模块在返回的顶级JSON字典中都有自己的密钥。

{
    "first_module_name": "Module's data",
    "second_module_name": "Module's data",
    "etc.": "etc."
}

3.检索原始文件: download-file

download-file方法可用于下载邮件附件,或直接从iCloud下载更多深奥文件。

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode "device=DEVICE_ID"
          --data-urlencode "file=FILE_ID"
          https://api.icloudextractor.com/c/download-file/
          -o PATH_TO_SAVE_FILE

所需的参数是session_key ,目标device_idfile_id 。上面的请求将下载文件并使用-o选项将指定的路径存储为curl

file_ids are either stored files in iCloud, or identifiers for hosted files on the internet. In the former case, file_ids are built from SHA-1 hashes of a file's AppDomain and filename. In the latter case we may process and decrypt the file before returning it.

file_ids may be previously known for static files, or can be obtained from message feeds, where they are used as identifiers by attachments.

提交有效的文件请求

如果传递给方法的值有效,它将返回HTTP响应正文中的二进制文件内容。

HTTP/1.1 200 OK

提交不存在文件的文件请求

如果iCloud上没有文件,或者我们无法从相应的第三方检索文件,则该方法仍将成功返回,但邮件正文将为空。

HTTP/1.1 200 OK

会话过期后提交文件请求

如果会话已过期,将向客户端提供错误的请求响应代码。

HTTP/1.1 400 BAD REQUEST
{"message": "Your iCloud session has expired. To continue, please sign in again.",
 "error": "key-invalid"}

示例file_id s

与用于直接文件访问的应用相关联的公共散列键包括以下内容。

  • 3d0d7e5fb2ce288813306e4d4636395e047a3d28短信
  • 1b6b187a1b60b9ae8b720c79e2c67f472bab09c0 WhatsApp
  • 1c6a49018bcace96656e4fe8f08d572ce071b92c WhatsApp
  • 7c7fba66680ef796b916b067077cc246adacf01d WhatsApp
  • b39bac0d347adfaf172527f97c3a5fa3df726a3a Viber
  • 8e281be6657d4523710d96341b6f86ba89b56df7 Kik
  • ff1324e6b949111b2fb449ecddb50c89c3699a78通话
  • a49bfab36504be1bf563c1d1813b05efd6076717来电
  • 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca电话
  • 5a4935c78a5255723f707230a451d79c540d2741电话
  • 12b144c0bd44f2b3dffd9186d3f9c05b917cee25照片
  • adb8c77534444e97c31ff15924d50f3ed1fbd3b1
  • 2041457d5fe04d39d0ab481178355df6781e6858约会
  • 3ecf3efff3a55d6155efce2828579e8a3cd881c1浏览历史
  • cd89f9e10d3497912bfc92e5dc674ca989cfdd44浏览历史
  • 2d711a1f5613f5259730b98328a3f7e816698f88线

一些信使应用程序 - 例如Skype,Facebook Messenger和微信 - 根据会话改变了file_id

4.使用身份验证令牌刷新帐户登录

auth_token是Apple的登录令牌。它持续至少一天,并在向API上的refresh-session端点发出请求时refresh-session 。每次轮询refresh-session端点都需要持久保存此令牌。

由于refresh-session端点仅需要auth_token作为输入并返回设备列表以及新的会话密钥,因此可以使用它在API上启动新会话,而无需再次登录该帐户。这对于启用2FA / 2SV的帐户特别有用,因为只需要为初始sign-in请求完成身份验证过程。

要使用它,必须使用登录期间检索到的auth_token字段。必须将其发送到refresh-session端点。

auth_token参数从初始sign-in请求返回,必须用于refresh-session端点。

我们建议在请求中包含可选参数account ,因为这有助于我们通过整个系统监控请求。此参数的值只是用户的iCloud帐户用户名。

CURL_CALL --data-urlencode "auth_token=AUTHENTICATION_TOKEN"
          --data-urlencode "account=ICLOUD_EMAIL"
          https://api.icloudextractor.com/c/refresh-session/

提交无效的身份验证令牌

如果令牌无效,端点将返回错误的请求代码。

HTTP/1.1 400 BAD REQUEST
{"message": "Invalid auth_token.",
 "error": "invalid-parameter"}

提交有效的身份验证令牌

响应将类似于登录端点:新创建的会话密钥和更新的设备列表,其中包含识别每个元数据所需的所有元数据。可以使用新会话继续提取数据。

HTTP/1.1 200 OK

5.删除iCloud Photo Library文件: delete-file

delete-file方法可用于从iCloud照片库中删除照片。它接受filekeypermament标志作为参数。

CURL_CALL --data-urlencode "key=SESSION_KEY"
          --data-urlencode "file=FILE_ID"
          --data-urlencode "permanent=False"
          https://api.icloudextractor.com/c/delete-file/

file参数将包含照片的id(可通过web_photos feed检索),而permanent标志控制文件是软还是硬删除。如果将其设置为False ,则该请求将使文件移动到“最近删除的”照片相册(称为软删除)。另一方面,如果将其设置为True ,则该请求将从“最近删除的”相册中删除该文件,并将使其永久删除(称为硬删除)。

成功的软删除

如果软删除成功,照片将被移动到“最近删除”的相册,它将返回成功消息。

HTTP/1.1 200 OK
{
  "message": "Success: File number: FILE_ID has been recycled."
}

成功的硬删除

如果硬删除成功,则当这些设备下次同步到iCloud时,照片将从关联的设备中删除。但是,由于使用了该技术,硬件删除的文件仍然可以从Reincubate的iCloud Photo API中发现并可下载不确定的时间。此行为可用于取消删除未列出的文件。

请注意,对于要硬删除的文件,必须先将其软删除。

HTTP/1.1 200 OK
{
  "message": "Success: File number: FILE_ID has been deleted permanently."
}

软删除失败

如果请求失败,它将返回错误响应。

HTTP/1.1 400 BAD REQUEST
{
  "message": "Failure: File number: FILE_ID was not deleted."
}

使用本机SDK加速下载

对于高度并行化的文件下载,我们提供了一个C ++ SDK,允许客户端在本地下载和解密文件,避免了download-file端点的开销(但却失去了方便)。此SDK适用于Linux(Ubuntu 12.04,Ubuntu 14.04,Debian Jessie)和Windows。

它与API的其他工作流程集成在一起。

下载

用户可以加载当前库并调用SDK入口点DownloadFiles ,它具有以下签名:

int DownloadFiles(const wchar_t* clientID, const wchar_t* clientKey, const wchar_t* sessionKey,
                  const wchar_t* deviceID, const wchar_t** fileIDs, size_t fileIDs_count,
                  const wchar_t* targetDir, ProgressFunction progFunc, void* progParam,
                  GetWStringBuffer getErrorBuffer)

使用这些外部回调定义:

typedef wchar_t* (*GetWStringBuffer)(size_t size);
typedef bool(*ProgressFunction)(double percent, unsigned long long downloadedSize,
                                unsigned long long totalSize, void* param);

参数是:

  • clientID API客户端ID。
  • clientKey API客户端密钥。
  • sessionKey当前会话密钥。
  • deviceID目标设备ID。
  • fileIDs所需file_ids数组。
  • fileIDs_count fileIDs数组的长度。
  • targetDir输出文件的目录。
  • progFunc Progress回调函数,每次进行进度更新时都会调用该函数。
  • progParam可以传递给progFunc回调的自定义参数。
  • getErrorBuffer这个回调函数应该返回一个缓冲区,它将保存下载过程中出现的错误。

下载完成后,请求的文件ID将位于targetDir指定的文件夹中。

较旧的SDK版本

在旧版本中,DownloadFiles入口点的签名略有不同:

int DownloadFiles(const wchar_t* clientID, const wchar_t* clientKey, const wchar_t* sessionKey,
                  const wchar_t* deviceID, const wchar_t** fileIDs, size_t fileIDs_count,
                  const wchar_t* targetDir, ProgressFunction progFunc, void* progParam,
                  GetWStringBuffer getReplyBuffer, GetWStringBuffer getErrorBuffer)

附加参数是:

  • getReplyBuffergetErrorBuffer类似,此回调函数负责返回DownloadFiles方法可以写入的有效缓冲区。在这种情况下,此缓冲区将包含具有下载最终状态的回复。

帐户和设备停用和重新激活

The `client-management` method allows for clients to deactive or reactivate billing for account or device access. The methods for deactivation and reactivation have separate endpoints.

##### Account deactivation

```bash
CURL_CALL --data-urlencode "account=ACCOUNT_ID"
          https://api.icloudextractor.com/c/client-management/deactivation/
帐户重新启动
CURL_CALL --data-urlencode "account=ACCOUNT_ID"
          https://api.icloudextractor.com/c/client-management/activation/
设备停用
CURL_CALL --data-urlencode "device=DEVICE_ID"
          https://api.icloudextractor.com/c/client-management/deactivation/
设备重新激活
CURL_CALL --data-urlencode "device=DEVICE_ID"
          https://api.icloudextractor.com/c/client-management/activation/

提交有效请求

如果传递给帐户停用方法的值有效,它将在HTTP响应正文中返回一条消息。

HTTP/1.1 200 OK
{"message": "deactivation has been set to True for account: ACCOUNT_ID"}

如果用户请求停用设备,则在HTTP响应正文中返回类似的消息:

HTTP/1.1 200 OK
{"message": "deactivation has been set to True for device: DEVICE_ID"}

提交包含无效凭据的请求

如果用户请求停用或重新激活具有无效account_id或无效device_id的帐户,或者如果account_iddevice_id未与该用户关联,则它将返回HTTP 400。

HTTP/1.1 400 BAD REQUEST
{"message": "no device with device ID: BAD_DEVICE_ID",
 "error": "bad-device"}

对于无效的account_id或未与用户关联的account_id ,将返回类似的错误和消息。

HTTP/1.1 400 BAD REQUEST
{"message": "no account with account ID: ACCOUNT_ID",
 "error": "bad-account"}

重复请求

如果用户请求在该状态下已存在的设备或帐户被停用或重新激活,则会在HTTP响应正文中返回一条消息,通知用户所请求的device_idaccount_id已处于请求状态:

HTTP/1.1 200 OK
{"message": "deactivation is already set to True for account: ACCOUNT_ID "}

如果重复请求设备停用和重新激活以及帐户重新激活,则会显示类似的消息。

请求停用帐户或设备的数据

如果用户从已停用的帐户或设备请求数据,则它将是HTTP 403:

HTTP/1.1 403 FORBIDDEN
{"message": "The requested account has been deactivated",
 "error": "deactivated-account"}

同样,在从停用的帐户请求数据的情况下给出类似的消息。

Feed返回消息:“联系enterprise@reincubate.com以访问此数据”

使用演示密钥时将返回此消息。有关访问更多数据的试用密钥,请与我们联系。如果您已有试用密钥,是否在客户端实现中正确指定了它?

我正在尝试通过file_id拉取应用程序的数据库文件,但我没有收到任何数据

file_ids are derived from an SHA-1 hash of the file's path and name, so they are constant for any given file. If the file's attributes or content change, it won't affect the hash.

但是,有时应用程序作者会更改他们存储数据的文件的名称(有时Apple会在新的iOS版本中执行)。这就是为什么,例如,在获取WhatsApp数据时需要检查几个不同的file_idfile_id更新应用程序时都可以更改这些file_id

建议用户使用JSON提要而不是使用文件并直接操作它们。使用feed,无需担心SQL,PList解析或取消删除的功效,并且使用源更快更简单。

我从服务器收到速率限制错误

API速率限制请求超过15分钟窗口,并且每个密钥配置此限制。出于安全考虑,大多数密钥都是速率限制的。

API客户端根据它们收到的HTTP标头响应中的限制返回其使用情况的数据。这些响应使用以下标头:

  • X-Rate-Limit-Limit 15分钟窗口内允许的请求数。
  • X-Rate-Limit-Remaining当前窗口分配中剩余的请求数。
  • X-Rate-Limit-Reset直到当前速率限制窗口结束的剩余时间,以毫秒为单位。

以下是来自1,000请求速率限制的密钥的一组示例实时标头。

X-Rate-Limit-Remaining: 995
X-Rate-Limit-Limit: 1000
X-Rate-Limit-Reset: 3546.3297081

如果达到速率限制,服务器将响应:

HTTP/1.1 429 TOO MANY REQUESTS

服务器将在此响应中包含三个速率限制标头。

正确的客户端行为是等待X-Rate-Limit-Reset指定的持续时间通过,此时将重置X-Rate-Limit-Remaining

我收到了一封关于远程访问我访问的iCloud帐户的电子邮件

轮询传统的实时馈送模块(如上面的示例馈送模块标志部分中所述)可以触发将电子邮件发送到与该iCloud帐户关联的地址。请注意,这适用于旧版实时馈送模块,而不适用于生产模块。

我们能帮你什么吗?

我们的支持团队在这里提供帮助!

我们的办公时间是格林威治标准时间周一至周五上午9点至下午5点。 时间目前是 7:06 AM的 GMT。

我们力争在一个工作日内答复所有垂询。

转到支持部分 › 联系企业团队 ›
我们的支持团队非常棒

我们可以改进这篇文章吗?

我们喜欢听取用户的意见:为什么不给我们发电子邮件,发表评论或发推文 @reincubate?

© 2008 - 2019 Reincubate Ltd. 保留所有权利。 在英格兰和威尔士注册 #5189175, VAT GB151788978. Reincubate®是注册商标。 隐私权和条款. 我们推荐多因素认证。 在伦敦建立了爱情。