स्टेटमेंट लिस्ट सिंटैक्स

स्टेटमेंट की सूची, JSON-encoded फ़ाइल या स्निपेट होती है. यह एक जानी-पहचानी जगह पर मौजूद होती है.

स्टेटमेंट की सूची की जगह

यह सूची कहां सेव करनी चाहिए, यह जानने के लिए स्टेटमेंट की सूची बनाना लेख पढ़ें.

सिंटैक्स

स्टेटमेंट की सूची या स्निपेट में, एक या उससे ज़्यादा वेबसाइट या ऐप्लिकेशन के स्टेटमेंट का JSON कलेक्शन होता है. ये स्टेटमेंट किसी भी क्रम में हो सकते हैं. यहां सामान्य सिंटैक्स दिया गया है:

[
  {
    "relation": ["relation_string"],
    "target": {target_object}
  } , ...
]

relation

एक या उससे ज़्यादा स्ट्रिंग का ऐरे, जो टारगेट के बारे में बताए गए संबंध के बारे में बताता है. तय की गई संबंध स्ट्रिंग की सूची देखें. उदाहरण: delegate_permission/common.handle_all_urls

टारगेट

वह टारगेट ऐसेट जिस पर यह स्टेटमेंट लागू होता है. उपलब्ध टारगेट टाइप:

• वेबसाइट टारगेट

  "target": {
    "namespace": "web",
    "site": "site_root_url"
  }

  नाम स्थान

  वेबसाइटों के लिए web होना चाहिए.

  साइट

  उस साइट का यूआरआई जिसे स्टेटमेंट में टारगेट किया गया है. यह http[s]://<hostname>[:<port>] फ़ॉर्मैट में होता है. इसमें <hostname> पूरी तरह से क्वालिफ़ाइड होता है. साथ ही, एचटीटीपी के लिए पोर्ट 80 या एचटीटीपीएस के लिए पोर्ट 443 का इस्तेमाल करते समय, <port> को शामिल नहीं किया जाना चाहिए. वेबसाइट टारगेट सिर्फ़ रूट डोमेन हो सकता है. इसे किसी खास सबडायरेक्ट्री तक सीमित नहीं किया जा सकता. इस रूट के तहत आने वाली सभी डायरेक्ट्री मैच होंगी. सबडोमेन को मैच नहीं माना जाना चाहिए. इसका मतलब है कि अगर स्टेटमेंट फ़ाइल www.example.com पर होस्ट की गई है, तो www.puppies.example.com को मैच नहीं माना जाना चाहिए. वेबसाइट टारगेट मैचिंग के नियमों और उदाहरणों के लिए, टारगेट का दस्तावेज़ देखें. उदाहरण: http://www.example.com

• Android ऐप्लिकेशन टारगेट

  "target": {
    "namespace": "android_app",
    "package_name": "fully_qualified_package_name",
    "sha256_cert_fingerprints": ["cert_fingerprint"]
  }

  नाम स्थान

  Android ऐप्लिकेशन के लिए android_app होना ज़रूरी है.

  package_name

  यह स्टेटमेंट जिस ऐप्लिकेशन पर लागू होता है उसके पैकेज का पूरा नाम. उदाहरण: com.google.android.apps.maps

  sha256_cert_fingerprints

  यह उस ऐप्लिकेशन के सर्टिफ़िकेट का कैपिटल लेटर वाला SHA256 फ़िंगरप्रिंट है जिस पर यह स्टेटमेंट लागू होता है. इसे openssl या Java keytool का इस्तेमाल करके, यहां दिखाए गए तरीके से कैलकुलेट किया जा सकता है:

  • openssl x509 -in $CERTFILE -noout -fingerprint -sha256
  • keytool -printcert -file $CERTFILE | grep SHA256

  उदाहरण: ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"].

  अगर आपके ऐप्लिकेशन के लिए Play ऐप्लिकेशन साइनिंग का इस्तेमाल किया जा रहा है, तो आम तौर पर keytool या openssl को स्थानीय तौर पर चलाने से जनरेट हुआ सर्टिफ़िकेट फ़िंगरप्रिंट, उपयोगकर्ताओं के डिवाइसों पर मौजूद फ़िंगरप्रिंट से मेल नहीं खाता. Play Console डेवलपर खाते में जाकर, यह पुष्टि की जा सकती है कि आपके ऐप्लिकेशन के लिए Play ऐप्लिकेशन पर हस्ताक्षर करने की सुविधा का इस्तेमाल किया जा रहा है या नहीं. इसके लिए, Release > Setup > App Integrity पर जाएं. अगर इस सुविधा का इस्तेमाल किया जा रहा है, तो आपको उसी पेज पर अपने ऐप्लिकेशन के लिए सही डिजिटल ऐसेट लिंक JSON स्निपेट भी दिखेगा.

relation_extensions (ज़रूरी नहीं)

आपके पास किसी स्टेटमेंट में relation_extensions फ़ील्ड जोड़ने का विकल्प होता है. इससे उन अनुमतियों और असोसिएशन के बारे में ज़्यादा जानकारी दी जा सकती है जिन्हें आपको अनुमति देनी है. यह फ़ील्ड एक ऑब्जेक्ट होना चाहिए. इसमें हर कुंजी एक रिलेशन स्ट्रिंग होती है और वैल्यू एक ऐसा ऑब्जेक्ट होता है जिसमें उस रिलेशन के एक्सटेंशन शामिल होते हैं. इन स्टेटमेंट का अनुरोध करने वाले क्लाइंट को इन फ़ील्ड के हिसाब से अपडेट किया जाना चाहिए.

उदाहरण के लिए, delegate_permission/common.handle_all_urls संबंध के लिए relation_extensions ऐसा दिख सकता है:

  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": ["..."]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {...}
    }
  }
  

DAL API, एपीआई कॉल में relation_extensions को वापस लाने की सुविधा देता है. ऐसा तब होता है, जब अनुरोध में return_relation_extensions=true पैरामीटर सेट किया गया हो.

स्टेटमेंट की सूची का उदाहरण

यहां वेबसाइट के स्टेटमेंट की सूची का एक उदाहरण दिया गया है. इसमें वेबसाइटों और ऐप्लिकेशन, दोनों के बारे में स्टेटमेंट शामिल हैं: http://example.digitalassetlinks.org/.well-known/assetlinks.json

कई स्टेटमेंट या उससे ज़्यादा स्टेटमेंट को स्केल करना

कुछ मामलों में, प्रिंसिपल अलग-अलग टारगेट के बारे में कई अलग-अलग स्टेटमेंट देना चाहेगा. इसके अलावा, ऐसा भी हो सकता है कि एक ही सेट के टारगेट के लिए, अलग-अलग प्रिंसिपल से स्टेटमेंट जारी करने की ज़रूरत हो. उदाहरण के लिए, कोई वेबसाइट हर देश के हिसाब से अलग-अलग टॉप लेवल डोमेन पर उपलब्ध हो सकती है. साथ ही, उन सभी डोमेन पर एक ही मोबाइल ऐप्लिकेशन के बारे में जानकारी दी जा सकती है.

इन स्थितियों में, include स्टेटमेंट मददगार हो सकते हैं. इस तरीके का इस्तेमाल करके, कई अलग-अलग प्रिंसिपल से एक ही जगह पर पॉइंटर सेट अप किए जा सकते हैं. यह जगह, सभी प्रिंसिपल के लिए स्टेटमेंट तय करती है.

उदाहरण के लिए, हो सकता है कि आपको केंद्रीय जगह के तौर पर `https://example.com/includedstatements.json` को सेट करना हो. इस फ़ाइल को ऊपर दिए गए उदाहरणों में मौजूद कॉन्टेंट के हिसाब से कॉन्फ़िगर किया जा सकता है.

किसी वेबसाइट से, शामिल की गई फ़ाइल पर पॉइंटर सेट अप करने के लिए, `https://example.com/.well-known/assetlinks.json` को इसमें बदलें:

[{
  "include": "https://example.com/includedstatements.json"
}]

किसी Android ऐप्लिकेशन से include फ़ाइल में पॉइंटर सेट अप करने के लिए, `res/values/strings.xml` को इसमें बदलें:

<resources>
  ...
  <string name="asset_statements">
    [{
      \"include\": \"https://example.com/includedstatements.json\"
    }]
  </string>
</resources>

ज़्यादा जानकारी

स्टेटमेंट लिस्ट के फ़ॉर्मैट और इससे जुड़े सिद्धांतों के बारे में ज़्यादा जानकारी, हमारे स्पेसिफ़िकेशन दस्तावेज़ में दी गई है.