इस पेज का अनुवाद Cloud Translation API से किया गया है.

FedCM के अपडेट: Continuation API बंडल और Storage Access API के लिए ऑरिजिन ट्रायल की सुविधा अपने-आप अनुमति देना

Eiji Kitamura

Chrome 126 से, डेवलपर डेस्कटॉप फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट एपीआई (FedCM) की सुविधाओं के एक बंडल के लिए, ऑरिजिन ट्रायल शुरू कर सकते हैं. इससे उन्हें इस्तेमाल के कुछ मामलों में अनुमति देने की सुविधा मिलती है. बंडल में Continuation API और पैरामीटर एपीआई शामिल होता है, जो OAuth की पुष्टि करने के फ़्लो जैसा अनुभव चालू करता है. इसमें आइडेंटिटी प्रोवाइडर (आईडीपी) से मिला अनुमति वाला डायलॉग शामिल होता है. बंडल में, फ़ील्ड एपीआई, कई configURL, और कस्टम खाता लेबल जैसे अन्य बदलाव भी शामिल हैं. Chrome 126 में, हम Storage Access API (SAA) के लिए ऑरिजिन ट्रायल भी शुरू कर रहे हैं. यह SAA के अनुरोधों को तब अपने-आप स्वीकार करता है, जब उपयोगकर्ता ने FedCM का इस्तेमाल करके पहले भी लॉग इन किया हो.

ऑरिजिन ट्रायल: FedCM Continuation API का बंडल

FedCM Continuation API के बंडल में कई FedCM एक्सटेंशन होते हैं:

कंटिन्युएशन एपीआई
पैरामीटर एपीआई
फ़ील्ड एपीआई
एक से ज़्यादा configURL
कस्टम खाता लेबल

कंटिन्यूएशन एपीआई

कोई उपयोगकर्ता आरपी में साइन इन करके, बटन मोड का इस्तेमाल करके अनुमति दे रहा है.

Glitch पर एपीआई का डेमो देखा जा सकता है.

कंटिन्युएशन एपीआई, आईडीपी के आईडी दावे का एंडपॉइंट को वैकल्पिक तौर पर एक यूआरएल दिखाता है, जिसे FedCM रेंडर करके उपयोगकर्ता को एक से ज़्यादा चरणों में साइन इन करने की प्रोसेस जारी रखने की अनुमति देता है. इससे आईडीपी (IdP) को, उपयोगकर्ता से अनुरोध करने की अनुमति मिलती है कि वह भरोसेमंद पक्ष (आरपी) को वह अनुमतियां दे जो FedCM के मौजूदा यूज़र इंटरफ़ेस (यूआई) में दी जा सकती है. जैसे, उपयोगकर्ता के सर्वर साइड रिसॉर्स का ऐक्सेस.

आम तौर पर, आईडी एश्योरेशन एंडपॉइंट, पुष्टि करने के लिए ज़रूरी टोकन दिखाता है.

{
  "token": "***********"
}

हालांकि, Continuation API की मदद से, आईडी दावा एंडपॉइंट एक continue_on प्रॉपर्टी दिखा सकता है, जिसमें आईडी दावा एंडपॉइंट के लिए ऐब्सलूट पाथ या मिलता-जुलता पाथ शामिल होता है.

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

जैसे ही ब्राउज़र को continue_on रिस्पॉन्स मिलता है, एक नई पॉप-अप विंडो खुलती है और उपयोगकर्ता को तय किए गए पाथ पर ले जाती है.

जब उपयोगकर्ता पेज से इंटरैक्ट करता है, जैसे कि आरपी के साथ ज़्यादा जानकारी शेयर करने की अनुमति देता है, तो ओरिजनल navigator.credentials.get() कॉल को हल करने के लिए, आईडीपी पेज IdentityProvider.resolve() को कॉल कर सकता है और आर्ग्युमेंट के तौर पर टोकन दिखा सकता है.

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

इसके बाद, ब्राउज़र अपने-आप पॉप-अप बंद कर देगा और एपीआई कॉलर को टोकन वापस कर देगा.

अगर उपयोगकर्ता अनुरोध अस्वीकार कर देता है, तो IdentityProvider.close() को कॉल करके विंडो को बंद किया जा सकता है.

IdentityProvider.close();

ध्यान दें: Continuation API सिर्फ़ तब इस्तेमाल किया जा सकता है, जब उपयोगकर्ता से इंटरैक्शन (अश्लील क्लिक) हुआ हो. इसलिए, उपयोगकर्ता को विजेट मोड (mediation: 'required' के साथ) या बटन मोड में से कोई एक खाता चुनना होगा. बटन मोड में, उपयोगकर्ता को हमेशा खाता चालू करना होगा. हालांकि, mediation: silent के लिए पॉप-अप की अनुमति नहीं है. mediation: optional विजेट मोड के लिए, एपीआई यह जांच करता है कि उपयोगकर्ता ऐक्टिव है या नहीं. ऐसा तब होता है, जब अपने-आप फिर से पुष्टि करने की सुविधा चालू हो. अगर ऐसा नहीं होता है, तो कोई पॉप-अप विंडो नहीं खुलती और वादा अस्वीकार कर दिया जाता है.

अगर किसी वजह से उपयोगकर्ता ने पॉप-अप में अपना खाता बदल दिया है (उदाहरण के लिए, आईडीपी "उपयोगकर्ता स्विच करें" फ़ंक्शन ऑफ़र करता है या किसी दूसरे को खाता इस्तेमाल करने की अनुमति दी गई है), तो resolve कॉल में एक वैकल्पिक दूसरा आर्ग्युमेंट होता है. इसकी मदद से, ये काम किए जा सकते हैं:

IdentityProvider.resolve(token, {accountId: '1234');

Parameters API

Parameters API, आरपी को आईडी दावे के एंडपॉइंट के लिए ज़्यादा पैरामीटर देने की अनुमति देता है. Parameters API की मदद से, आरपी, IdP को अतिरिक्त पैरामीटर पास कर सकते हैं, ताकि वे बुनियादी साइन-इन के अलावा संसाधनों के लिए अनुमतियों का अनुरोध कर सकें. उपयोगकर्ता, Continuation API के ज़रिए लॉन्च किए गए, आईडीपी के कंट्रोल वाले यूज़र इंटरफ़ेस (यूएक्स) फ़्लो के ज़रिए इन अनुमतियों को अनुमति देगा.

एपीआई का इस्तेमाल करने के लिए, navigator.credentials.get() कॉल में ऑब्जेक्ट के तौर पर params प्रॉपर्टी में पैरामीटर जोड़ें.

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

params ऑब्जेक्ट में प्रॉपर्टी के नामों के आगे param_ जोड़ा जाता है. ऊपर दिए गए उदाहरण में, पैरामीटर प्रॉपर्टी में IDP_SPECIFIC_PARAM को '1' के तौर पर, foo को 'BAR', ETC को 'MOAR', और scope को 'calendar.readonly photos.write' के तौर पर शामिल किया गया है. अनुरोध के एचटीटीपी मुख्य हिस्से में, इसका अनुवाद param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write के तौर पर किया जाएगा:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

डायनैमिक तौर पर अनुमतियां पाएं

आम तौर पर, उपयोगकर्ताओं के लिए अनुमतियों का अनुरोध तब करना सबसे ज़्यादा मददगार होता है, जब उन्हें ज़रूरत हो. ऐसा तब नहीं करना चाहिए, जब डेवलपर को लगता है कि अनुमतियों को लागू करना आसान है. उदाहरण के लिए, उपयोगकर्ता के वेबसाइट पर आने के तुरंत बाद अनुमति मांगने के बजाय, फ़ोटो लेने के समय कैमरे का ऐक्सेस मांगना बेहतर होता है. यही तरीका सर्वर के संसाधनों पर भी लागू होता है. अनुमतियों के लिए सिर्फ़ तब अनुरोध करें, जब वे उपयोगकर्ता के लिए ज़रूरी हों. इसे "डाइनैमिक अनुमति" कहा जाता है.

FedCM की मदद से, डाइनैमिक तौर पर अनुमति का अनुरोध करने के लिए, आईडीपी ये काम कर सकता है:

navigator.credentials.get() को ज़रूरी पैरामीटर के साथ कॉल करें, ताकि आईडीपी उन्हें समझ सके. जैसे, scope.
आईडी से जुड़े दावे का एंडपॉइंट से इस बात की पुष्टि होती है कि उपयोगकर्ता ने पहले से साइन इन किया हुआ है और इसके जवाब में continue_on यूआरएल शामिल किया जाता है.
ब्राउज़र, आईडीपी (IdP) के अनुमति वाले पेज पर एक पॉप-अप विंडो खोलता है. इसमें, अनुरोध किए गए दायरों से मेल खाने वाली अतिरिक्त अनुमति मांगी जाती है.
IdP से IdentityProvider.resolve() के ज़रिए अनुमति मिलने के बाद, विंडो बंद हो जाती है और आरपी के मूल navigator.credentials.get() कॉल को काम का टोकन या ऑथराइज़ेशन कोड मिल जाता है, ताकि आरपी उसे सही ऐक्सेस टोकन से बदल सके.

फ़ील्ड एपीआई

Fields API की मदद से, आरपी, आईडीपी से अनुरोध करने के लिए खाते के एट्रिब्यूट की जानकारी दे सकता है, ताकि ब्राउज़र, FedCM डायलॉग में जानकारी ज़ाहिर करने वाला सही यूज़र इंटरफ़ेस (यूआई) रेंडर कर सके. यह आईडीपी की ज़िम्मेदारी है कि वह दिखाए गए टोकन में अनुरोध किए गए फ़ील्ड शामिल करे. OpenID Connect में "बुनियादी प्रोफ़ाइल" और OAuth में "दायरे" के लिए अनुरोध करने के उदाहरण के तौर पर देखें.

विजेट मोड में, जानकारी ज़ाहिर करने वाला मैसेज. — विजेट मोड में जानकारी ज़ाहिर करने वाला मैसेज.

बटन मोड में, जानकारी ज़ाहिर करने वाला मैसेज.

फ़ील्ड एपीआई का इस्तेमाल करने के लिए, fields प्रॉपर्टी में navigator.credentials.get() कॉल में अरे के तौर पर पैरामीटर जोड़ें. फ़िलहाल, फ़ील्ड में 'name', 'email', और 'picture' शामिल हो सकते हैं. हालांकि, आने वाले समय में और वैल्यू शामिल करने के लिए, इन्हें बड़ा किया जा सकता है.

fields वाला अनुरोध कुछ ऐसा दिखेगा:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

आईडी दावे के एंडपॉइंट के लिए एचटीटीपी अनुरोध में, आरपी के हिसाब से तय किया गया fields पैरामीटर शामिल होता है. अगर यह लौटने वाला उपयोगकर्ता नहीं है, तो disclosure_text_shown पैरामीटर को true के तौर पर सेट किया जाता है. साथ ही, ब्राउज़र ने disclosure_shown_for पैरामीटर में वे फ़ील्ड भी शामिल किए हैं जिनके बारे में ब्राउज़र ने उपयोगकर्ता को बताया है:

POST /id_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

अगर आरपी को आईडीपी (IdP) के किसी अतिरिक्त डेटा का ऐक्सेस चाहिए, जैसे कि कैलेंडर का ऐक्सेस, तो इस डेटा को ऊपर बताए गए कस्टम पैरामीटर की मदद से मैनेज किया जाना चाहिए. अनुमति का अनुरोध करने के लिए, आईडीपी (IdP) एक continue_on यूआरएल दिखाता है.

अगर fields खाली कलेक्शन है, तो अनुरोध कुछ ऐसा दिखेगा:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

अगर fields खाली अरे है, तो उपयोगकर्ता एजेंट जानकारी देने वाले यूज़र इंटरफ़ेस (यूआई) को छोड़कर आगे बढ़ जाएगा.

जानकारी ज़ाहिर करने वाला मैसेज, विजेट मोड में नहीं दिखता. बटन के फ़्लो में, जानकारी देने वाले यूज़र इंटरफ़ेस (यूआई) को पूरी तरह से स्किप कर दिया गया है. — विज्ञापन में ज़ाहिर की जाने वाली जानकारी वाला मैसेज, विजेट मोड में नहीं दिखता. बटन के फ़्लो में, जानकारी देने वाले यूज़र इंटरफ़ेस (यूआई) को पूरी तरह से स्किप कर दिया गया है.

ऐसा तब भी होता है, जब accounts endpoint के रिस्पॉन्स में ऐसा क्लाइंट आईडी न हो जो approved_clients में मौजूद आरपी से मेल खाता हो.

इस मामले में, आईडी दावे के एंडपॉइंट को भेजा गया disclosure_text_shown, एचटीटीपी के मुख्य हिस्से में गलत है:

POST /id_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false

एक से ज़्यादा configURLs

एक से ज़्यादा configURLs की मदद से, आईडीपी (IdP) एक से ज़्यादा कॉन्फ़िगरेशन फ़ाइलों को शामिल कर सकते हैं. इसके लिए, well-known फ़ाइल में accounts_endpoint और login_url को कॉन्फ़िगरेशन फ़ाइलों की तरह ही तय करना होगा.

अगर जानी-पहचानी फ़ाइल में accounts_endpoint और login_url को जोड़ा जाता है, तो provider_urls को अनदेखा कर दिया जाता है, ताकि आईडीपी (IdP) कई कॉन्फ़िगरेशन फ़ाइलों के साथ काम कर सके. अगर ऐसा नहीं है, तो provider_urls लागू रहेगा, ताकि वह पुराने सिस्टम के साथ काम कर सके.

एक से ज़्यादा configURLs के साथ काम करने वाली .well-known फ़ाइल इस तरह दिख सकती है:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

इससे हमें ये काम करने में मदद मिलती है:

पहले से मौजूद लोकप्रिय फ़ाइलों और ब्राउज़र के उन पुराने वर्शन के साथ काम करना जो पहले से ही इस्तेमाल में हैं.
कॉन्फ़िगरेशन फ़ाइलों की संख्या जितनी चाहे उतनी हो सकती है. हालांकि, यह ज़रूरी है कि वे सभी एक ही accounts_endpoint और login_url पर ले जाएं.
accounts_endpoint से किए गए क्रेडेंशियल वाले फ़ेच अनुरोध में, एन्ट्रापी को जोड़ने का कोई मौका नहीं है, क्योंकि इसे ".well-known" लेवल पर बताना होता है.

एक से ज़्यादा configURLs का इस्तेमाल करना ज़रूरी नहीं है. साथ ही, FedCM के मौजूदा लागू होने की स्थिति में कोई बदलाव नहीं होगा.

कस्टम खाता लेबल

कस्टम खाता लेबल FedCM आईडीपी को खातों को एनोटेट करने की अनुमति देते हैं. इससे आरपी, कॉन्फ़िगरेशन फ़ाइल में लेबल तय करके उन्हें फ़िल्टर कर सकता है. navigator.credentials.get() कॉल में डोमेन हिंट एपीआई और लॉगिन हिंट एपीआई का इस्तेमाल करके, उपयोगकर्ताओं को इसी तरह फ़िल्टर किया जा सकता है. हालांकि, कस्टम खाता लेबल, कॉन्फ़िगरेशन फ़ाइल की जानकारी देकर उपयोगकर्ताओं को फ़िल्टर कर सकते हैं. यह सुविधा तब खास तौर पर काम की होती है, जब एक से ज़्यादा configURL का इस्तेमाल किया जाता है. कस्टम खाता लेबल इस मामले में भी अलग होते हैं कि वे आईडीपी सर्वर से मिलते हैं, न कि आरपी से, लॉगिन करने या डोमेन के संकेत जैसे.

उदाहरण

आईडीपी (IdP) में उपभोक्ता और एंटरप्राइज़ के लिए, दो कॉन्फ़िगरेशन यूआरएल इस्तेमाल किए जा सकते हैं. उपभोक्ता कॉन्फ़िगरेशन फ़ाइल में 'consumer' लेबल और एंटरप्राइज़ कॉन्फ़िगरेशन फ़ाइल में 'enterprise' लेबल है.

इस तरह के सेटअप के साथ, जानी-मानी फ़ाइल में accounts_endpoint और login_url शामिल होते हैं, ताकि एक से ज़्यादा कॉन्फ़िगरेशन वाले यूआरएल को अनुमति दी जा सके.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

जब accounts_endpoint को .well-known फ़ाइल में दिया जाता है, तो provider_urls को अनदेखा कर दिया जाता है. आरपी, navigator.credentials.get() कॉल में सीधे जुड़ी कॉन्फ़िगरेशन फ़ाइलों पर ले जा सकता है.

कंज्यूमर कॉन्फ़िगरेशन फ़ाइल https://idp.example/fedcm.json में है. इसमें accounts प्रॉपर्टी शामिल है, जो include का इस्तेमाल करके 'consumer' के बारे में बताती है.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

एंटरप्राइज़ कॉन्फ़िगरेशन फ़ाइल https://idp.example/enterprise/fedcm.json में होती है. इसमें accounts प्रॉपर्टी शामिल होती है, जो include का इस्तेमाल करके 'enterprise' के बारे में बताती है.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

सामान्य आईडीपी (IdP) खाते का एंडपॉइंट (इस उदाहरण में https://idp.example/accounts) से उन खातों की सूची मिलती है जिनमें हर खाते के कलेक्शन में labels असाइन की गई लेबल प्रॉपर्टी होती है. नीचे एक ऐसे उपयोगकर्ता के जवाब का उदाहरण दिया गया है जिसके पास दो खाते हैं. एक वर्शन, उपभोक्ता के लिए है और दूसरा वर्शन, एंटरप्राइज़ के लिए:

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

जब आरपी, 'enterprise' उपयोगकर्ताओं को साइन इन करने की अनुमति देना चाहता है, तो वह navigator.credentials.get() कॉल में 'enterprise' कॉन्फ़िगरेशन यूआरएल 'https://idp.example/enterprise/fedcm.json' तय कर सकता है:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

इस वजह से, उपयोगकर्ता के लिए सिर्फ़ '4567' खाता आईडी ही साइन इन करने के लिए उपलब्ध होता है. '123' का खाता आईडी, ब्राउज़र से छिपी रहती है. इससे, उपयोगकर्ता को कोई ऐसा खाता नहीं दिया जाता जो इस साइट के आईडीपी (IdP) के साथ काम नहीं करता.

ध्यान दें:

लेबल, स्ट्रिंग होते हैं. अगर labels कलेक्शन या include फ़ील्ड में कुछ ऐसा है जो स्ट्रिंग नहीं है, तो उसे अनदेखा कर दिया जाता है.
अगर configURL में कोई लेबल नहीं दिया गया है, तो सभी खाते FedCM खाता चुनने की सुविधा में दिखाए जाएंगे.
अगर किसी खाते के लिए कोई लेबल तय नहीं किया गया है, तो यह खाता चुनने के विकल्प में सिर्फ़ तब दिखेगा, जब configURL में किसी लेबल के बारे में नहीं बताया गया होगा.
अगर विजेट के फ़्लो में, अनुरोध किए गए लेबल से कोई भी खाता मेल नहीं खाता (जैसे कि Domain hint API की तरह), तो FedCM डायलॉग में एक लॉगिन प्रॉम्प्ट दिखता है. इसकी मदद से, उपयोगकर्ता आईडीपी खाते में लॉग इन कर सकता है. बटन फ़्लो के लिए, लॉगिन पॉप-अप विंडो सीधे खुलती है.

ऑरिजिन ट्रायल: Storage Access API के लिए ट्रस्ट सिग्नल के तौर पर FedCM

Chrome 126, Storage Access API के लिए ट्रस्ट सिग्नल के तौर पर FedCM का ऑरिजिन ट्रायल शुरू कर रहा है. इस बदलाव के बाद, FedCM से पहले दी गई अनुमति, स्टोरेज ऐक्सेस करने वाले एपीआई से स्टोरेज के ऐक्सेस के अनुरोध को अपने-आप मंज़ूरी देने की मान्य वजह बन जाती है.

यह तब काम आता है, जब एम्बेड किया गया कोई iframe, पसंद के मुताबिक बनाए गए संसाधनों को ऐक्सेस करना चाहता है: उदाहरण के लिए, अगर idp.example को rp.example में एम्बेड किया गया है और उसे मनमुताबिक बनाए गए संसाधन दिखाने हों. अगर ब्राउज़र तीसरे पक्ष की कुकी के ऐक्सेस पर पाबंदी लगाता है, भले ही उपयोगकर्ता ने FedCM के साथ idp.example का इस्तेमाल करके rp.example में साइन इन किया हो, तो एम्बेड किया गया idp.example iframe, पसंद के मुताबिक बनाए गए संसाधनों के लिए अनुरोध नहीं कर पाएगा. ऐसा इसलिए, क्योंकि अनुरोधों में तीसरे पक्ष की कुकी शामिल नहीं होंगी.

ऐसा करने के लिए, idp.example को वेबसाइट पर एम्बेड किए गए iframe के ज़रिए, स्टोरेज ऐक्सेस करने की अनुमति लेनी होगी. यह अनुमति, सिर्फ़ अनुमति वाले प्रॉम्प्ट के ज़रिए ही मिल सकती है.

स्टोरेज ऐक्सेस एपीआई के लिए ट्रस्ट सिग्नल के तौर पर FedCM का इस्तेमाल करके, Storage Access API से जुड़ी अनुमति की जांच की जाती है. इससे न सिर्फ़ स्टोरेज ऐक्सेस प्रॉम्प्ट से मिलने वाली अनुमति को स्वीकार किया जाता है, बल्कि FedCM प्रॉम्प्ट से मिली अनुमति को भी स्वीकार किया जाता है.

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

उपयोगकर्ता के FedCM से साइन इन करने के बाद, उसे अनुमति अपने-आप मिल जाती है. हालांकि, ऐसा तब तक होता रहेगा, जब तक FedCM की पुष्टि करने की सुविधा चालू रहती है. इसका मतलब है कि उपयोगकर्ता के डिसकनेक्ट होने के बाद, अनुमति का अनुरोध करने पर एक प्रॉम्प्ट दिखेगा.

ऑरिजिन ट्रायल में हिस्सा लेना

Chrome 126 या इसके बाद के वर्शन पर, Chrome का कोई फ़्लैग चालू करके, FedCM Continuation API बंडल को स्थानीय तौर पर आज़माया जा सकता हैchrome://flags#fedcm-authz. Chrome 126 या उसके बाद के वर्शन पर #fedcm-with-storage-access-api को चालू करके, स्टोरेज ऐक्सेस एपीआई के लिए, भरोसे के सिग्नल के तौर पर FedCM को भी आज़माया जा सकता है.

ये सुविधाएं, ऑरिजिन ट्रायल के तौर पर भी उपलब्ध हैं. ऑरिजिन ट्रायल की मदद से, नई सुविधाओं को आज़माया जा सकता है. साथ ही, इन सुविधाओं के इस्तेमाल करने में आसानी, काम के होने, और असरदार होने के बारे में सुझाव, शिकायत या राय दी जा सकती है. ज़्यादा जानकारी के लिए, ऑरिजिन ट्रायल का इस्तेमाल शुरू करना लेख पढ़ें.

FedCM Continuation API बंडल ऑरिजिन ट्रायल आज़माने के लिए, दो ऑरिजिन ट्रायल टोकन बनाएं:

मुफ़्त में आज़माने के लिए रजिस्टर करें. आईडीपी के ऑरिजिन में टोक़न को एम्बेड करें.
ऑरिजिन ट्रायल के लिए रजिस्टर करने के लिए, तीसरे पक्ष के मैचिंग चेकबॉक्स पर सही का निशान लगाएं. आरपी के लिए टोकन जोड़ने के लिए, आरपी के लिए तीसरे पक्ष के ऑरिजिन ट्रायल को रजिस्टर करें में दिए गए निर्देशों का पालन करें.

अगर आपको बटन के फ़्लो के साथ-साथ Continuation API को चालू करना है, तो बटन मोड एपीआई के ऑरिजिन ट्रायल को भी चालू करें:

ऑरिजिन ट्रायल के लिए तीसरे पक्ष के तौर पर रजिस्टर करें. आरपी के लिए टोकन एम्बेड करने के लिए, आरपी के लिए तीसरे पक्ष के ऑरिजिन ट्रायल को रजिस्टर करें में दिए गए निर्देशों का पालन करें.

Storage Access API के ऑरिजिन ट्रायल के लिए, FedCM को भरोसे के सिग्नल के तौर पर आज़माने के लिए:

ऑरिजिन ट्रायल के लिए रजिस्टर करें. आईडीपी (IdP) ऑरिजिन के लिए टोकन को एम्बेड करें.

Continuation API बंडल का ऑरिजिन ट्रायल और Storage Access API के ऑरिजिन ट्रायल के लिए, भरोसे के सिग्नल के तौर पर FedCM, Chrome 126 से उपलब्ध है.

आरपी के लिए, तीसरे पक्ष का ऑरिजिन ट्रायल रजिस्टर करें

ऑरिजिन ट्रायल के रजिस्ट्रेशन पेज पर जाएं.
टोकन का अनुरोध करने के लिए, रजिस्टर करें बटन पर क्लिक करें और फ़ॉर्म भरें.
आईडीपी का ऑरिजिन, वेब ऑरिजिन के तौर पर डालें.
अन्य ओरिजिन पर JavaScript की मदद से टोकन इंजेक्ट करने के लिए, तीसरे पक्ष की मैचिंग की जांच करें.
सबमिट करें पर क्लिक करें.
जारी किए गए टोकन को तीसरे पक्ष की वेबसाइट पर जोड़ें.

किसी तीसरे पक्ष की वेबसाइट पर टोकन को एम्बेड करने के लिए, आईडीपी (IdP) की JavaScript लाइब्रेरी या उसके ऑरिजिन से इस्तेमाल किए जाने वाले SDK टूल में यहां दिया गया कोड जोड़ें.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

TOKEN_GOES_HERE की जगह अपना टोकन डालें.