ตั้งแต่ Chrome 126 เป็นต้นไป นักพัฒนาซอฟต์แวร์จะเริ่มเรียกใช้ช่วงทดลองใช้จากต้นทางสำหรับแพ็กเกจฟีเจอร์ Federated Credential Management API (FedCM) ในเดสก์ท็อปที่เปิดใช้กรณีการใช้งานการให้สิทธิ์ได้ แพ็กเกจดังกล่าวประกอบด้วย Continuation API และ Parameters API ซึ่งจะเปิดใช้ประสบการณ์ที่เหมือนกับขั้นตอนการให้สิทธิ์ OAuth ซึ่งเกี่ยวข้องกับกล่องโต้ตอบสิทธิ์ของผู้ให้บริการข้อมูลประจำตัว (IdP) แพ็กเกจนี้ยังรวมการเปลี่ยนแปลงอื่นๆ เช่น Fields API, configURL หลายรายการ และป้ายกำกับบัญชีที่กำหนดเอง จาก Chrome 126 เราจะเปิดตัวช่วงทดลองใช้จากต้นทางสำหรับ Storage Access API (SAA) ซึ่งจะส่งคำขอ SAA โดยอัตโนมัติหากผู้ใช้เคยเข้าสู่ระบบด้วย FedCM สำเร็จ
ช่วงทดลองใช้จากต้นทาง: แพ็กเกจ FedCM Continuation API
แพ็กเกจ FedCM Continuation API ประกอบด้วยส่วนขยาย FedCM หลายรายการ ได้แก่
API ความต่อเนื่อง
คุณสามารถดูการสาธิตของ API ใน Glitch
Continuation API จะอนุญาตให้ปลายทางการยืนยันรหัสของ IdP แสดง URL ที่ FedCM แสดงผลเพื่ออนุญาตให้ผู้ใช้ดำเนินการตามขั้นตอนการลงชื่อเข้าใช้แบบหลายขั้นตอนต่อได้ วิธีนี้ช่วยให้ IdP สามารถขอผู้ใช้ให้สิทธิ์ฝ่ายที่มีอำนาจ (RP) นอกเหนือจากสิ่งที่ทำได้ใน UI ของ 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
หน้าต่างป๊อปอัปใหม่จะเปิดขึ้นและนำทางผู้ใช้ไปยังเส้นทางที่ระบุ
หลังจากที่ผู้ใช้โต้ตอบกับหน้าเว็บ เช่น การให้สิทธิ์เพิ่มเติมเพื่อแชร์ข้อมูลเพิ่มเติมกับ RP หน้า IdP จะเรียกใช้ IdentityProvider.resolve()
เพื่อแก้ไขการเรียกใช้ navigator.credentials.get()
เดิมและแสดงผลโทเค็นเป็นอาร์กิวเมนต์ได้
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);
});
จากนั้นเบราว์เซอร์จะปิดป๊อปอัปเองและส่งคืนโทเค็นไปยังการเรียก API
หากผู้ใช้ปฏิเสธคำขอ คุณสามารถปิดหน้าต่างได้โดยการโทรหา IdentityProvider.close()
IdentityProvider.close();
หากผู้ใช้เปลี่ยนบัญชีในป๊อปอัปด้วยเหตุผลบางอย่าง (เช่น IdP มีฟังก์ชัน "เปลี่ยนผู้ใช้" หรือในกรณีการมอบสิทธิ์) การเรียกใช้การแก้ไขจะใช้อาร์กิวเมนต์ที่ 2 ที่ระบุหรือไม่ก็ได้ โดยให้มีเงื่อนไขดังนี้
IdentityProvider.resolve(token, {accountId: '1234');
API พารามิเตอร์
Parameters API ช่วยให้ RP ระบุพารามิเตอร์เพิ่มเติมไปยังปลายทางการยืนยันรหัสได้ เมื่อใช้ Parameters API แล้ว RP สามารถส่งพารามิเตอร์เพิ่มเติมไปยัง IdP เพื่อขอสิทธิ์สำหรับทรัพยากรนอกเหนือจากการลงชื่อเข้าใช้ขั้นพื้นฐานได้ ผู้ใช้จะให้สิทธิ์เหล่านี้ผ่านขั้นตอน UX ที่ควบคุมโดย IdP ที่เปิดใช้ผ่าน Continuation API
หากต้องการใช้ API ให้เพิ่มพารามิเตอร์ลงในพร็อพเพอร์ตี้ params
เป็นออบเจ็กต์ในการเรียก navigator.credentials.get()
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¶m_foo=BAR¶m_ETC=MOAR¶m_scope=calendar.readonly%20photos.write
ในเนื้อหา HTTP ของคำขอ
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¶m_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_scope=calendar.readonly%20photos.write
รับสิทธิ์แบบไดนามิก
โดยทั่วไปแล้ว การขอสิทธิ์ในเวลาที่จำเป็นจะมีประโยชน์มากที่สุดสำหรับผู้ใช้ แทนการขอสิทธิ์ในเวลาที่จำเป็นต้องใช้ แทนเวลาที่นักพัฒนาซอฟต์แวร์รู้สึกว่าตนใช้งานง่ายที่สุด ตัวอย่างเช่น การขอสิทธิ์เข้าถึงกล้องเมื่อผู้ใช้กำลังจะถ่ายภาพจะเป็นการขออนุญาตทันทีที่ผู้ใช้มาถึงเว็บไซต์ ใช้แนวทางปฏิบัติเดียวกันกับทรัพยากรของเซิร์ฟเวอร์ โปรดขอสิทธิ์เมื่อจำเป็นสำหรับผู้ใช้เท่านั้น ซึ่งเรียกว่า "การให้สิทธิ์แบบไดนามิก"
หากต้องการขอสิทธิ์แบบไดนามิกด้วย FedCM ผู้ให้บริการข้อมูลประจำตัวจะทำสิ่งต่อไปนี้ได้
- เรียก
navigator.credentials.get()
พร้อมพารามิเตอร์ที่จำเป็นซึ่ง IdP เข้าใจได้ เช่นscope
- ปลายทางการยืนยันรหัสจะยืนยันว่าผู้ใช้ได้ลงชื่อเข้าใช้แล้ว และตอบกลับด้วย URL ของ
continue_on
- เบราว์เซอร์จะเปิดหน้าต่างป๊อปอัปที่มีหน้าสิทธิ์ของ IdP ซึ่งขอสิทธิ์เพิ่มเติมที่ตรงกับขอบเขตที่ขอ
- เมื่อ IdP ให้สิทธิ์ผ่าน
IdentityProvider.resolve()
แล้ว หน้าต่างจะปิดลงและการเรียกใช้navigator.credentials.get()
เดิมของ RP จะได้รับโทเค็นที่เกี่ยวข้องหรือรหัสการให้สิทธิ์เพื่อให้ RP แลกเปลี่ยนโทเค็นกับโทเค็นเพื่อการเข้าถึงที่เหมาะสมได้
API ช่อง
Fields API ช่วยให้ RP ประกาศแอตทริบิวต์ของบัญชีเพื่อขอจาก IdP เพื่อให้เบราว์เซอร์แสดงผล UI การเปิดเผยข้อมูลที่เหมาะสมในกล่องโต้ตอบ FedCM ได้ IdP มีหน้าที่รวมช่องที่จำเป็นต้องขอในโทเค็นที่แสดงผล พิจารณาถึงการขอ "โปรไฟล์พื้นฐาน" ใน OpenID Connect เทียบกับ "ขอบเขต" ใน OAuth
![ข้อความเปิดเผยข้อมูลในโหมดวิดเจ็ต](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-widget.jpg?authuser=5&hl=th)
![ข้อความเปิดเผยข้อมูลในโหมดปุ่ม](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-button.jpg?authuser=5&hl=th)
หากต้องการใช้ Fields API ให้เพิ่มพารามิเตอร์ลงในพร็อพเพอร์ตี้ 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',
});
คำขอ HTTP ที่ส่งไปยังปลายทางการยืนยันรหัสจะมีพารามิเตอร์ fields
ที่ระบุโดย RP โดยตั้งค่าพารามิเตอร์ 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
หาก RP ต้องการเข้าถึงข้อมูลเพิ่มเติมจาก IdP เช่น การเข้าถึงปฏิทิน ควรจัดการด้วยพารามิเตอร์ที่กําหนดเองดังที่กล่าวไว้ข้างต้น โดย IdP จะแสดง URL 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
เป็นอาร์เรย์ว่างเปล่า User Agent จะข้าม UI การเปิดเผยข้อมูล
![ข้อความเปิดเผยข้อมูลจะไม่แสดงในโหมดวิดเจ็ต ในขั้นตอนของปุ่ม ระบบจะข้าม UI การเปิดเผยข้อมูลทั้งหมด](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-without-disclosure-widget.jpg?authuser=5&hl=th)
ถึงแม้ว่าการตอบสนองจากปลายทางบัญชีจะไม่มีรหัสไคลเอ็นต์ที่ตรงกับ RP ใน approved_clients
ก็ตาม
ในกรณีนี้ disclosure_text_shown
ที่ส่งไปยังปลายทางการยืนยันรหัสจะเป็นเท็จในเนื้อความ HTTP ดังนี้
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
configURL หลายรายการ
configURL หลายรายการช่วยให้ IdP รองรับไฟล์การกำหนดค่าหลายไฟล์สำหรับ IdP โดยการระบุ accounts_endpoint
และ login_url
ในไฟล์ที่รู้จักกันดีเหมือนกับไฟล์การกำหนดค่า
หากเพิ่ม accounts_endpoint
และ login_url
ลงในไฟล์ที่รู้จัก ระบบจะละเว้น provider_urls
เพื่อให้ IdP รองรับไฟล์การกำหนดค่าหลายไฟล์
หากไม่เป็นเช่นนั้น provider_urls
จะยังคงมีผลอยู่เพื่อให้ใช้งานร่วมกันได้แบบย้อนหลัง
ไฟล์ที่รู้จักซึ่งรองรับ configURL หลายรายการอาจมีลักษณะดังนี้
{
"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"
การรองรับ configURL หลายรายการนั้นไม่บังคับ และการใช้งาน FedCM ที่มีอยู่จะยังคงเหมือนเดิม
ป้ายกำกับบัญชีที่กำหนดเอง
ป้ายกำกับบัญชีที่กำหนดเองช่วยให้ FedCM
IdP ใส่คำอธิบายประกอบบัญชีเพื่อให้ RP กรองบัญชีเหล่านั้นได้โดยการระบุป้ายกำกับในไฟล์การกำหนดค่า ผู้ใช้สามารถกรองที่คล้ายกันได้โดยใช้ Domain Hint API และ Login
Hint API โดยการระบุในการเรียกใช้ navigator.credentials.get()
แต่ป้ายกำกับบัญชีที่กำหนดเองสามารถกรองผู้ใช้ได้โดยการระบุไฟล์การกำหนดค่า ซึ่งมีประโยชน์มากเมื่อใช้ configURLs หลายรายการ นอกจากนี้ ป้ายกำกับบัญชีที่กำหนดเองยังมีความแตกต่างจากมาจากเซิร์ฟเวอร์ IdP ซึ่งต่างจาก RP เช่น การเข้าสู่ระบบหรือการแนะนำโดเมน
ตัวอย่าง
IdP รองรับ configURL 2 รายการสำหรับผู้ใช้ทั่วไปและ Enterprise ตามลำดับ ไฟล์การกำหนดค่าผู้บริโภคมีป้ายกำกับ 'consumer'
และไฟล์การกำหนดค่าขององค์กรมีป้ายกำกับ 'enterprise'
เมื่อใช้การตั้งค่าเช่นนี้ ไฟล์ที่รู้จักกันดีจะรวม accounts_endpoint
และ login_url
เพื่ออนุญาตให้มี configURL หลายรายการได้
{
"provider_urls": [ "https://idp.example/fedcm.json" ],
"accounts_endpoint": "https://idp.example/accounts",
"login_url": "https://idp.example/login"
}
เมื่อมีการระบุ accounts_endpoint
ในไฟล์ที่รู้จัก ระบบจะไม่สนใจ provider_urls
RP จะชี้ไปที่ไฟล์การกำหนดค่าที่เกี่ยวข้องในการเรียกใช้ navigator.credentials.get()
ได้โดยตรง
ไฟล์การกำหนดค่าผู้บริโภคอยู่ที่ https://idp.example/fedcm.json
ซึ่งมีพร็อพเพอร์ตี้ accounts
ที่ระบุ 'consumer'
โดยใช้ include
{
"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
ที่ระบุ 'enterprise'
โดยใช้ include
{
"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
ที่กำหนดในอาร์เรย์ของแต่ละบัญชี
ต่อไปนี้เป็นตัวอย่างคำตอบสำหรับผู้ใช้ที่มี 2 บัญชี ส่วนหนึ่งมีไว้สำหรับผู้บริโภค ส่วนอีกส่วนหนึ่งมีไว้สำหรับองค์กร
{
"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"]
}]
}
เมื่อ RP ต้องการอนุญาตให้ผู้ใช้ 'enterprise'
ลงชื่อเข้าใช้ ก็สามารถระบุ 'enterprise'
configURL 'https://idp.example/enterprise/fedcm.json'
ในการเรียกใช้ navigator.credentials.get()
ได้ดังนี้
let { token } = await navigator.credentials.get({
identity: {
providers: [{
clientId: '1234',
nonce: '234234',
configURL: 'https://idp.example/enterprise/fedcm.json',
},
}
});
ด้วยเหตุนี้ ผู้ใช้จึงลงชื่อเข้าใช้ได้เฉพาะรหัสบัญชีของ '4567'
เท่านั้น เบราว์เซอร์จะซ่อนรหัสบัญชีของ '123'
ไว้อย่างเงียบๆ เพื่อไม่ให้ผู้ใช้เข้าถึงบัญชีที่ IdP ไม่ได้รองรับในเว็บไซต์นี้
ช่วงทดลองใช้จากต้นทาง: FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API
Chrome 126 กำลังเริ่มการทดลองใช้ FedCM จากต้นทางเป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API การเปลี่ยนแปลงนี้ทำให้การให้สิทธิ์ก่อนหน้านี้ผ่าน FedCM กลายเป็นเหตุผลอันสมควรที่จะอนุมัติคำขอเข้าถึงพื้นที่เก็บข้อมูลจาก API การเข้าถึงพื้นที่เก็บข้อมูลโดยอัตโนมัติ
วิธีนี้มีประโยชน์เมื่อ iframe ที่ฝังไว้ต้องการเข้าถึงทรัพยากรที่ปรับให้เหมาะกับแต่ละบุคคล เช่น หาก idp.example ฝังอยู่ใน rp.example และจำเป็นต้องแสดงทรัพยากรที่ปรับเปลี่ยนในแบบของคุณ หากเบราว์เซอร์จำกัดการเข้าถึงคุกกี้ของบุคคลที่สาม แม้ว่าผู้ใช้จะลงชื่อเข้าใช้ rp.example โดยใช้ idp.example กับ FedCM ก็ตาม iframe idp.example ที่ฝังจะไม่สามารถขอทรัพยากรที่ปรับเปลี่ยนในแบบของคุณได้เนื่องจากคำขอไม่มีคุกกี้ของบุคคลที่สาม
ดังนั้น idp.example จะต้องได้รับสิทธิ์การเข้าถึงพื้นที่เก็บข้อมูลผ่าน iframe ที่ฝังอยู่ในเว็บไซต์ ซึ่งสามารถได้รับผ่านข้อความแจ้งสิทธิ์เท่านั้น
เมื่อใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API การตรวจสอบสิทธิ์ 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 ยังทำงานอยู่ ซึ่งหมายความว่าเมื่อผู้ใช้ถูกตัดการเชื่อมต่อ คำขอสิทธิ์จะแสดงข้อความแจ้ง
เข้าร่วมช่วงทดลองใช้จากต้นทาง
คุณลองใช้แพ็กเกจ FedCM Continuation API ในเครื่องได้โดยเปิดธง
Chrome
chrome://flags#fedcm-authz
ใน Chrome 126 ขึ้นไป นอกจากนี้ คุณยังลองใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API ในเครื่องได้โดยเปิด #fedcm-with-storage-access-api
ใน Chrome 126 ขึ้นไป
ฟีเจอร์เหล่านี้มีให้บริการเป็นช่วงทดลองใช้จากต้นทางด้วย ช่วงทดลองใช้จากต้นทางช่วยให้คุณได้ลองใช้ฟีเจอร์ใหม่ๆ และแสดงความคิดเห็นเกี่ยวกับความสามารถในการใช้งาน การใช้งานจริง และประสิทธิภาพ ดูข้อมูลเพิ่มเติมได้ที่เริ่มต้นใช้งานช่วงทดลองใช้จากต้นทาง
หากต้องการลองทดลองใช้แพ็กเกจ FedCM Continuation API จากต้นทาง ให้สร้างโทเค็นช่วงทดลองใช้จากต้นทาง 2 รายการ ดังนี้
- ลงทะเบียนทดลองใช้ ฝังโทเค็นไปยังต้นทาง IdP
- ลงทะเบียนช่วงทดลองใช้จากต้นทางโดยเลือกช่องทำเครื่องหมายการจับคู่ของบุคคลที่สามไว้ ทำตามวิธีการในหัวข้อลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP เพื่อฝังโทเค็นสำหรับ RP
หากคุณสนใจที่จะเปิดใช้ Continuation API พร้อมกับโฟลว์ของปุ่ม ให้เปิดใช้งานการทดลองใช้ต้นทางของ API โหมดปุ่มด้วย ดังนี้
- ลงทะเบียนช่วงทดลองใช้จากต้นทางในฐานะบุคคลที่สาม ทำตามวิธีการในลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP เพื่อฝังโทเค็นสำหรับ RP
หากต้องการลองใช้ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับช่วงทดลองใช้ Storage Access API จากต้นทาง ให้ทำดังนี้
- ลงทะเบียนช่วงทดลองใช้จากต้นทาง ฝังโทเค็นไปยังต้นทาง IdP
ช่วงทดลองใช้แพ็กเกจ Continuation API จากต้นทางและ FedCM เป็นสัญญาณความน่าเชื่อถือสำหรับช่วงทดลองใช้ Storage Access API จากต้นทางมีให้บริการใน Chrome 126
ลงทะเบียนช่วงทดลองใช้จากต้นทางของบุคคลที่สามสำหรับ RP
- ไปที่หน้าการลงทะเบียนช่วงทดลองใช้จากต้นทาง
- คลิกปุ่มลงทะเบียนและกรอกแบบฟอร์มเพื่อขอโทเค็น
- ป้อนต้นทางของ IdP เป็นต้นทางเว็บ
- ตรวจสอบการจับคู่ของบุคคลที่สามเพื่อแทรกโทเค็นด้วย JavaScript ในต้นทางอื่นๆ
- คลิกส่ง
- ฝังโทเค็นที่ออกบนเว็บไซต์ของบุคคลที่สาม
หากต้องการฝังโทเค็นในเว็บไซต์ของบุคคลที่สาม ให้เพิ่มโค้ดต่อไปนี้ลงในไลบรารี JavaScript หรือ SDK ของ IdP ที่แสดงผลจากต้นทางของ IdP
const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);
แทนที่ TOKEN_GOES_HERE
ด้วยโทเค็นของคุณเอง