iCloud API(v1)

更新しました

このドキュメントはReincubateのレガシーiCloud APIの使用をカバーしています。

概要

API、そして特にフィードは多くの大きな利点を提供します。

  • 統合のしやすさこのAPIはあらゆるレベルの開発チームにとって使いやすいものであり、クライアントがiCloud / CloudKitストレージまたはサードパーティのアプリケーションに関する高度な専門知識を持つ必要がなくなります。

    iCloudへのインターフェースを開発し維持することの複雑さは相当なものであり、その上に重なっているのは、コアiOSデータとアプリファイルのために複数のデータフォーマットをサポートする必要性です。 iOSはさまざまなデータ形式を使用するだけでなく、各アプリ(たとえばWhatsApp)は、アプリの更新に応じて週ごとに変わる可能性がある一連のデータ形式と構造を使用します。

    iOS 9、iOS 10、CloudKit、iCloud 8 + 9マージ、2SV / 2FA、部分スナップショット、トークン化、A9およびA9X:このAPIはすべての「難しい」機能をサポートしています。

  • 将来の校正 Reincubateは、現在および過去のiCloudおよびiOSデータフォーマットのサポートを維持することを約束しており、この分野で確かな実績があります。

    • iOSデータアクセスをサポートする1位 (2008年)
    • 暗号化されたiOSデータアクセスをサポートする1位 (2009)
    • iCloudデータ抽出をサポートする1位 (2011)
    • iCloud / CloudKit iOS 9データアクセスをサポートするAPIを搭載した1st&only (2015)
  • 比類のない専門知識へのサポートとアクセスアプリデータ会社としての同社の焦点と位置付けの結果として、Reincubateのチームはこの分野での比類のない経験と知識を持っています。この経験は、新しいアプリやユースケースを模索しているクライアントにとって特に有益です。

    JSONフィードのユーザーは、結果データがより正確になるように、アプリデータの抽出と削除の取り消しにおいてReincubateの独自技術を利用することができます。

  • すぐに使えるアプリのサポート 。別にコアiOSのデータ型から- すべてのデバイス上のすべてのiOSのバージョンでサポートされているすべてのその- APIは、サードパーティ製のアプリの数十をサポートするためのモジュールがあります。 WhatsApp、Viber、Kik、WeChat、Line、SnapChat、Facebook Messenger、Skypeなど、サポートされているアプリの中で最も人気のあるアプリがあります。

  • すぐに使える開発者プラットフォームのサポート 。このAPIには、 Python.NET / C#JavaScriptなど、さまざまな言語で利用できるオープンソースのクライアント実装がありJavaScript

  • スピードとスケーラビリティ Reincubate iCloud APIプラットフォームは拡張性に優れており、JSONフィードシステムは生のファイルアクセスよりも高速で拡張性に優れています。

  • 豊富なフィードのカスタマイズオプションフィードプラットフォームは、パートナー向けに簡単にカスタマイズできます。例としては、 protobuf形式のフィードやメッセージングアプリの添付ファイルの集約などがあります。

  • 信頼します。再インキュベートは、世界中のセキュリティ、LEA、および政府機関のユーザーから信頼されています。同社は英国の厳格なデータ保護法の適用を受けており、EUおよび米国のセーフハーバー規制に準拠しています。

入門

利害関係者は、APIキーへのアクセスについてエンタープライズチームに連絡できます。ただし、テストキーはすべてのサンプルクライアント実装に用意されています。

サンプルPythonクライアントのインストール

Python iCloudライブラリは単一のコマンドでインストールできます。従来のライブラリを入手するには、最新の1.*バージョンをインストールする必要があります。

$ pip install ricloud==1.*

このクライアントのソースはGitHubのricloud-pyにあります。

サンプルJavaScriptクライアントのインストール

JavaScript iCloudライブラリは単一のコマンドでインストールできます。従来のライブラリを入手するには、最新の1.*バージョンをインストールする必要があります。

$ npm install ricloud==1.*

このクライアントのソースはGitHubのricloud-jsにあります。

サンプル.NET / C#クライアントのインストール

C#iCloudライブラリは単一のコマンドでインストールできます。従来のライブラリを入手するには、最新の1.*バージョンをインストールする必要があります。

$ nuget install ricloud==1.*

このクライアントのソースはGitHubのricloud-csharpにあります。

設定

それぞれのクライアント実装はそれ自身のバンドルされたドキュメンテーションとそれがどのように使われることができるかを示すサンプルスクリプトと共に来ます。設定は通常、APIに対する認証のためのuserkey値の指定に限定されています。

APIを使用する

ユーザがAPIを使用して実行する必要があるかもしれない3つのコアオペレーションがあります。

  • 認証と列挙: sign-in perform-2fa-challenge submit-2fa-challenge
  • フィードデータへのアクセス: download-data
  • 生ファイルへのアクセス: download-file

このセクションの例はcurl形式で示されています。

APIに対して行われるすべての要求で、 curl-Lパラメーターを使用してリダイレクトを追跡するように指示される必要があります。カスタムAPIバージョンヘッダーの--header "Accept: application/vnd.icloud-api.v1" 、ユーザーのAPI資格情報も--user "USER:KEY"で設定する必要があります。したがって、これらの例のすべてのcurl呼び出しは、次のcurl列で始まる必要があります。

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

すべての要求がPOSTを通じて行われるため、 -X POSTオプションも指定されていることに注意してください。この呼び出しは変更されないため、以下ではCURL_CALLます。

一般的なガイドラインとして、すべての要求(エラーを除く)は現在のセッションを識別するsession_keyフィールドを返します。送信されない場合は、 sign-in要求を使用して新しいセッションを生成する必要があります。 session_key値は一貫して使用する必要があります。

1.認証、2FA / 2SV、およびデバイスとデータリストの取得

自分のアカウントで2要素認証または2段階認証を有効にしてユーザーとしてサインインするには、 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以外のアカウントでのサインインは、1回のリクエストで実行できます。

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でサインイン

アカウントが2要素認証でセキュリティ保護されている場合、 sign-in要求はtwo-factor authentication is enabled on this accountsession_key 、および2SVの場合にはtrustedDevicesリストでtwo-factor authentication is enabled on this accountいることを示すエラーメッセージを返します。

  • 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の場合、次のステップは、1つのtrustedDevices 2SVチャレンジコードを発行することtrustedDevices 。これを行うには、 perform-2fa-challengeperform-2fa-challengeするperform-2fa-challenge要求し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_keysign-in要求と同じになります。

  • 2FA

2FAの場合、違いはリクエストが空のtrustedDevicesリストを返すということ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の場合、信頼できるすべてのデバイスが自動的にチャレンジされるため、どのデバイスがチャレンジされるかを選択することはできません。これを行うには、challenge引数を付けずに、 perform-2fa-challengeperform-2fa-challengeするperform-2fa-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最終リクエストをemailpassword

APIキーでトークン化が有効になっている場合、応答にはauth_tokenエントリのみが含まれます。この場合は、 sign-inするのではなく、下記のセクション4で説明されているようにrefresh-session最後のリクエストを送信することをお勧めします。 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メソッドは、フィードデータにアクセスするために使用されます。

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_keydevice_idログイン応答からデバイスの一つの、そしてdata_maskあり、 ORユーザーが興味を持っているすべてのフィードモジュールのフラグの組み合わせ。あなたが指定することもできsinceデータの検索を開始する日付。

クライアントのAPIキーがこれらすべてのモジュールに対して有効であると仮定すると、メソッドは要求されたデータをJSON形式で返します。

有効なフィードリクエストを送信する

メソッドに渡された値が有効であれば、HTTPレスポンスボディのフィードコンテンツを返します。

HTTP/1.1 200 OK

欠落しているパラメーターを指定してフィード要求を送信する

必要なパラメータの1つが欠けていると、メソッドは不正な要求応答コードを返します。

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

無効なパラメータでフィードリクエストを送信する

無効な値または誤った形式の値がパラメータに送信された場合、メソッドは不正な要求応答コードを返します。

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

サンプルフィードモジュールのフラグ

以下のモジュールフラグは、 download-dataメソッドのmaskパラメータ用にまとめてmaskできます。これは完全なリストではありません。

  • 0000000000001メッセージ
  • 0000000000002写真とビデオ
  • 0000000000004ブラウザ履歴
  • 0000000000008通話履歴
  • 0000000000016連絡先
  • 0000000000032インストール済みアプリ
  • 0000000000256場所(ライブ)
  • 0000000000512 WhatsAppメッセージ
  • 0000000001024 Skypeメッセージ
  • 0000000002048カレンダー
  • 0000000004096行メッセージ
  • 0000000008192 Kikメッセージ
  • 0000000016384 Viberのメッセージ
  • 0000000032768 Facebookのメッセージ
  • 0000000065536 WeChatメッセージ
  • 0000000131072 Snapchatメッセージ
  • 0000000262144ファイルリスト
  • 0000000524288ブラウザ履歴(ライブ)
  • 0000001048576 WhatsApp通話履歴
  • 0000002097152 Viberの通話履歴
  • 0000004194304アプリの使い方
  • 0000008388608リアクション
  • 0000033554432 HealthKit
  • 0000067108864 HealthKitステップのみ
  • 0000134217728サファリクッキー
  • 0000268435456 Kikの連絡先
  • 0000536870912 Viberの連絡先
  • 0001073741824 Viberの会話
  • 0002147483648通話履歴(ライブ)
  • 所在地: 0004294967296
  • 0008589934592ハイキングメッセージ
  • 0017179869184チャットストーリー
  • 0034359738368ボイスメール
  • 0068719476736レコーディング
  • 0137438953472ビデオ
  • 0274877906944写真とビデオ(ライブ)
  • 0549755813888 Tinderメッセージ
  • 1099511627776リンクアップルウォッチ
  • 2199023255552ハイキングの投稿
  • 4398046511104連絡先(ライブ)
  • 8796093022208アカウント情報

たとえば、メッセージのフィード、通話履歴、ブラウザ履歴を要求するには、マスクは1 + 4 + 8 = 13ます。

JSONフィードフォーマット

JSONフィードは、できるだけ簡単に解析できるように設計されています。フィードは、単一の応答内で要求されたすべてのデータ型を返します。

moduleフラグで指定された各フィードモジュールは、返されるトップレベルの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_id 、およびfile_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

直接ファイルアクセス用のアプリに関連付けられている一般的なハッシュキーには、次のものがあります。

  • 3d0d7e5fb2ce288813306e4d4636395e047a3d28 SMS
  • 1b6b187a1b60b9ae8b720c79e2c67f472bab09c0 WhatsApp
  • 1c6a49018bcace96656e4fe8f08d572ce071b92c WhatsApp
  • 7c7fba66680ef796b916b067077cc246adacf01d WhatsApp
  • b39bac0d347adfaf172527f97c3a5fa3df726a3a Viber
  • 8e281be6657d4523710d96341b6f86ba89b56df7 Kik
  • ff1324e6b949111b2fb449ecddb50c89c3699a78呼び出し
  • a49bfab36504be1bf563c1d1813b05efd6076717通話
  • 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca電話
  • 5a4935c78a5255723f707230a451d79c540d2741通話
  • 12b144c0bd44f2b3dffd9186d3f9c05b917cee25写真
  • adb8c77534444e97c31ff15924d50f3ed1fbd3b1コンタクト
  • 2041457d5fe04d39d0ab481178355df6781e6858予定
  • 3ecf3efff3a55d6155efce2828579e8a3cd881c1閲覧履歴
  • cd89f9e10d3497912bfc92e5dc674ca989cfdd44閲覧履歴
  • 2d711a1f5613f5259730b98328a3f7e816698f88

Skype、Facebook Messenger、WeChatなどの一部のメッセンジャーアプリケーションでは、会話によってfile_id異なります。

4.認証トークンを使用したアカウントログインの更新

auth_tokenはAppleとのログイントークンです。それは少なくとも1日続き、API上のrefresh-sessionエンドポイントに要求が行われるとrefresh-sessionれます。 refresh-sessionエンドポイントへの毎日のポーリングは、このトークンを保持するために必要なすべてです。

refresh-sessionエンドポイントは入力としてauth_tokenのみを必要とし、デバイスリストと新しいセッションキーを返すので、アカウントに再度ログインすることなくAPIで新しいセッションを開始するために使用できます。認証プロセスは最初のsign-in要求に対してのみ完了する必要があるため、これは2FA / 2SV対応アカウントに特に便利です。

それを使うためには、ログイン中に取り出された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-filedelete-file

delete-filedelete-file方法は、iCloudフォトライブラリから写真を削除するために使用できます。 filekey 、およびpermamentフラグをパラメータとして受け入れfile

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フィードを通じて取得可能)と、ファイルをpermanent削除するのかpermanent削除するのかを制御するpermanentフラグを含めることがfileます。 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でダウンロードを高速化

高度に並列化されたファイルのダウンロードのために、 download-fileエンドポイントのオーバーヘッド(しかし利便性を失うこと)を避けて、クライアントがファイルをローカルにダウンロードおよび復号化することを可能にするC ++ SDKを提供します。この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プログレスコールバック関数。プログレスが更新されるたびに呼び出されます。
  • progParam progFuncコールバックに渡すことができるカスタムパラメータ。
  • getErrorBufferこのコールバック関数は、ダウンロード中に発生したエラーを保持するバッファを返します。

ダウンロードがtargetDirすると、要求されたファイル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)

追加のパラメーターは以下のとおりです。

  • getReplyBuffer getErrorBufferと同様に、このコールバック関数は、 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ユーザとassocitedされていません。

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

リクエストを繰り返す

ユーザーがデバイスまたはアカウントがその状態にあるときに非アクティブ化または再アクティブ化を要求すると、要求されたdevice_idまたはaccount_idが既に要求された状態にあることをユーザーに知らせるメッセージがHTTP応答本体に返されます。

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"}

また、無効化されたアカウントからデータを要求した場合にも、同様のメッセージが表示されます。

フィードがメッセージを返します。「このデータへのアクセスについては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.

ただし、アプリの作成者がデータを保存するファイルの名前を変更することがあります(新しいiOSのリリースではAppleが変更することもあります)。そのため、たとえば、WhatsAppデータを取得するときに調べるべきいくつかの異なるfile_idがあります。これらのfile_idは、アプリが更新されるたびに変更できます。

ファイルを操作して直接操作するのではなく、ユーザーがJSONフィードを取得することをお勧めします。フィードを使用すると、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

サーバーはこの応答に3つのレート制限ヘッダーを含めます。

正しいクライアントの動作は、 X-Rate-Limit-Reset指定された期間が経過するのを待つことです。この時点で、 X-Rate-Limit-Remainingはリセットされます。

アクセスしたiCloudアカウントへのリモートアクセスについてのメールが届きました

サンプルフィードモジュールのフラグセクションで前述したように、従来のライブフィードモジュールをポーリングすると、そのiCloudアカウントに関連付けられているアドレスに電子メールが送信されることがあります。これはレガシーライブフィードモジュールにのみ発生し、プロダクションモジュールには発生しません。

どのように我々は助けることができます?

サポートチームがお手伝いします!

営業時間は月曜日から金曜日の午前9時から午後5時(GMT)です。 時間は現在 2:58 PM GMTです。

1営業日以内に、お返事を差し上げます。メールアドレスはこちら。

サポートセクションに移動 › エンタープライズチームに連絡する ›
私たちの素晴らしいサポートチーム

この記事を改善できますか?

ユーザーからの連絡をお待ちしています。電子メールを送信したり、コメントを残したり、ツイートしたりしないでください。 @reincubate?

© 2008 - 2019 Reincubate Ltd. 無断複写・転載を禁じます。 イングランドとウェールズに登録 #5189175, VAT GB151788978. Reincubate®は登録商標です。 プライバシーと利用規約. マルチファクタ認証をお勧めします。 ロンドンで愛と建てられた。