กลยุทธ์ในการย้ายข้อมูลเว็บไซต์โดยใช้สตริง User Agent ไปยัง คำแนะนำใหม่เกี่ยวกับไคลเอ็นต์ User Agent
User-Agent string คือ การเก็บลายนิ้วมือแบบแพสซีฟที่สำคัญ แสดงผลในเบราว์เซอร์ รวมถึงความยากต่อการประมวลผล อย่างไรก็ตาม เรามีข้อมูลที่ถูกต้องทุกประเภท เหตุผลในการรวบรวมและประมวลผลข้อมูล User Agent ดังนั้นสิ่งที่ต้องมีคือ เพื่อหาโซลูชันที่ดีกว่า คำแนะนำสำหรับไคลเอ็นต์ User Agent เป็นทั้ง 2 วิธีที่ชัดเจน เพื่อประกาศความต้องการข้อมูล User Agent และวิธีส่งคืนข้อมูลใน รูปแบบที่ใช้งานง่าย
บทความนี้จะแนะนำคุณเกี่ยวกับการตรวจสอบสิทธิ์เข้าถึงข้อมูล User Agent และ ย้ายข้อมูลการใช้สตริง User Agent ไปยังคำแนะนำของไคลเอ็นต์ User Agent
การรวบรวมการตรวจสอบและการใช้ข้อมูล User Agent
คุณควรเข้าใจว่าทำไมถึงมีการรวบรวมข้อมูลลักษณะนี้ กำลังรวบรวมอยู่ ก้าวแรกโดยไม่คำนึงว่าคุณจะ ดำเนินการใดก็ตาม คือการทำความเข้าใจว่าคุณนำข้อมูล User Agent ไปใช้ที่ไหนและเพราะเหตุใด
หากไม่ทราบว่ามีการใช้ข้อมูล User Agent หรือไม่หรือที่ไหนบ้าง โปรดลองค้นหา
รหัสส่วนหน้าเพื่อใช้ navigator.userAgent และรหัสแบ็กเอนด์สำหรับ
ใช้ส่วนหัว HTTP User-Agent คุณควรตรวจสอบโค้ดส่วนหน้าด้วย
เพื่อใช้ฟีเจอร์ที่เลิกใช้งานแล้ว เช่น navigator.platform และ
navigator.appVersion
จากมุมมองด้านการใช้งาน ให้นึกถึงตำแหน่งใดก็ได้ในโค้ดของคุณซึ่งคุณอยู่ การบันทึกหรือประมวลผล:
- ชื่อหรือเวอร์ชันเบราว์เซอร์
- ชื่อระบบปฏิบัติการหรือเวอร์ชัน
- ยี่ห้อหรือรุ่นของอุปกรณ์
- ประเภท CPU, สถาปัตยกรรม หรือบิตเนส (เช่น 64 บิต)
อาจเป็นไปได้ว่าคุณอาจกำลังใช้ไลบรารีหรือบริการของบุคคลที่สามเพื่อ ประมวลผล User-agent ในกรณีนี้ ให้ตรวจดูว่าได้อัปเดตเป็น รองรับคำแนะนำไคลเอ็นต์ User Agent
คุณใช้เฉพาะข้อมูล User Agent พื้นฐานใช่ไหม
ชุดคำแนะนำเริ่มต้นของไคลเอ็นต์ User Agent มีดังนี้
Sec-CH-UA: ชื่อเบราว์เซอร์และเวอร์ชันหลัก/สำคัญSec-CH-UA-Mobile: ค่าบูลีนที่ระบุอุปกรณ์เคลื่อนที่Sec-CH-UA-Platform: ชื่อระบบปฏิบัติการ- โปรดทราบว่านี่เป็นการอัปเดตในข้อกำหนด และจะแสดงใน Chrome และเบราว์เซอร์อื่นๆ แบบ Chromium ในเร็วๆ นี้
สตริง User Agent เวอร์ชันแบบย่อที่มีการเสนอจะยังคงอยู่
ข้อมูลพื้นฐานนี้ในรูปแบบที่เข้ากันแบบย้อนหลังได้ ตัวอย่างเช่น แทนที่จะแสดง
Chrome/90.0.4430.85 สตริงจะมี Chrome/90.0.0.0
หากคุณต้องการตรวจสอบเฉพาะสตริง User Agent สำหรับชื่อเบราว์เซอร์ เวอร์ชันหลัก หรือระบบปฏิบัติการ โค้ดของคุณ จะยังคงทำงานต่อไปแม้ว่าคุณจะ เพื่อดูคำเตือนการเลิกใช้งาน
แม้ว่าคุณจะทำได้และควรย้ายข้อมูลไปยังคำแนะนำของไคลเอ็นต์ User Agent แต่คุณอาจมี โค้ดหรือข้อจำกัดทรัพยากร ที่ขัดขวางไม่ให้เกิดปัญหานี้ การลดลงของข้อมูลใน สตริง User Agent ในรูปแบบที่เข้ากันแบบย้อนหลังนี้มีไว้เพื่อให้มั่นใจว่า แม้ว่าโค้ดที่มีอยู่จะได้รับข้อมูลที่มีรายละเอียดน้อยกว่า แต่ก็ควรจะยังคง จะมีฟังก์ชันการทำงานพื้นฐานเหมือนเดิม
กลยุทธ์: JavaScript API ฝั่งไคลเอ็นต์แบบออนดีมานด์
หากคุณกำลังใช้ navigator.userAgent คุณควรเปลี่ยนไปใช้
ต้องการ navigator.userAgentData ก่อนที่จะกลับไปใช้การแยกวิเคราะห์
สตริง user-agent
if (navigator.userAgentData) {
// use new hints
} else {
// fall back to user-agent string parsing
}
หากคุณกำลังตรวจสอบอุปกรณ์เคลื่อนที่หรือเดสก์ท็อป ให้ใช้ค่า mobile บูลีน
const isMobile = navigator.userAgentData.mobile;
userAgentData.brands คืออาร์เรย์ของออบเจ็กต์ที่มี brand และ version
ที่เบราว์เซอร์สามารถแสดงรายการความเข้ากันได้
แบรนด์ คุณสามารถเข้าถึงคอลัมน์ดังกล่าวเป็นอาร์เรย์ได้โดยตรง หรือคุณอาจต้องการใช้
some() การเรียกเพื่อตรวจสอบว่ามีรายการที่ระบุหรือไม่
function isCompatible(item) {
// In real life you most likely have more complex rules here
return ['Chromium', 'Google Chrome', 'NewBrowser'].includes(item.brand);
}
if (navigator.userAgentData.brands.some(isCompatible)) {
// browser reports as compatible
}
หากคุณต้องการค่า User-agent ที่มีเอนโทรปีสูงซึ่งมีรายละเอียดมากกว่า คุณจะต้อง
ต้องระบุและตรวจสอบผลลัพธ์ใน Promise ที่แสดงผล
navigator.userAgentData.getHighEntropyValues(['model'])
.then(ua => {
// requested hints available as attributes
const model = ua.model
});
คุณยังอาจต้องใช้กลยุทธ์นี้หากต้องการเปลี่ยนจาก การประมวลผลฝั่งเซิร์ฟเวอร์สู่การประมวลผลฝั่งไคลเอ็นต์ JavaScript API จะไม่ ต้องมีสิทธิ์เข้าถึงส่วนหัวของคำขอ HTTP ดังนั้นสามารถขอค่า User Agent ได้ที่ จุดใดก็ได้
กลยุทธ์: ส่วนหัวฝั่งเซิร์ฟเวอร์แบบคงที่
หากคุณใช้ส่วนหัวของคำขอ User-Agent บนเซิร์ฟเวอร์และความต้องการของคุณ
ว่าข้อมูลดังกล่าวค่อนข้างสอดคล้องกันทั่วทั้งเว็บไซต์ จากนั้น
ให้ระบุคำแนะนำไคลเอ็นต์ที่ต้องการเป็นชุดแบบคงที่ในคำตอบของคุณ นี่คือ
แนวทางที่ค่อนข้างง่ายเนื่องจากโดยทั่วไปแล้วคุณต้องกำหนดค่า
ตำแหน่งนั้น ตัวอย่างเช่น อาจอยู่ในการกำหนดค่าเว็บเซิร์ฟเวอร์หากคุณ
เพิ่มส่วนหัวในหน้านั้น การกำหนดค่าโฮสติ้ง หรือการกำหนดค่าระดับบนสุดของ
เฟรมเวิร์กหรือแพลตฟอร์ม
ที่คุณใช้สำหรับเว็บไซต์ของคุณ
ลองใช้กลยุทธ์นี้หากคุณต้องการปรับเปลี่ยนหรือปรับแต่งคำตอบ แสดงโดยอิงตามข้อมูล User Agent
เบราว์เซอร์หรือโปรแกรมไคลเอ็นต์อื่นๆ อาจเลือกที่จะให้คำใบ้เริ่มต้นที่แตกต่างออกไป ดังนั้นจึงเป็น แนวทางปฏิบัติที่ดีคือการระบุทุกอย่างที่คุณต้องการ แม้ว่าโดยทั่วไปแล้วจะมีไว้ให้ "ค่าเริ่มต้น"
ตัวอย่างเช่น ค่าเริ่มต้นปัจจุบันสำหรับ Chrome จะแสดงเป็น
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA
หากคุณต้องการรับรุ่นอุปกรณ์ในคำตอบด้วย คุณต้อง ส่ง:
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA
เมื่อประมวลผลในฝั่งเซิร์ฟเวอร์ คุณควรตรวจสอบก่อนว่า
ส่งส่วนหัว Sec-CH-UA แล้ว จากนั้นเลือกส่วนหัว User-Agent สำรอง
แยกวิเคราะห์หากไม่พร้อมใช้งาน
กลยุทธ์: การมอบสิทธิ์ให้คำขอข้ามต้นทาง
หากคุณขอทรัพยากรย่อยแบบข้ามต้นทางหรือข้ามเว็บไซต์ที่ต้องใช้ ระบบจะส่งคำแนะนำไคลเอ็นต์ User Agent ตามคำขอ จากนั้นคุณจะต้องดำเนินการ ระบุคำแนะนำที่ต้องการอย่างชัดแจ้งโดยใช้นโยบายสิทธิ์
ตัวอย่างเช่น สมมติว่า https://blog.site โฮสต์ทรัพยากรบน
https://cdn.site ซึ่งสามารถแสดงผลทรัพยากรที่เพิ่มประสิทธิภาพสำหรับอุปกรณ์ที่เฉพาะเจาะจง
https://blog.site สามารถขอคำแนะนำSec-CH-UA-Modelได้ แต่จำเป็นต้อง
มอบสิทธิ์ให้กับ https://cdn.site อย่างชัดเจนโดยใช้ Permissions-Policy
ส่วนหัว รายการคําแนะนําที่มีการควบคุมตามนโยบายมีอยู่ในคําแนะนําของไคลเอ็นต์
โครงสร้างพื้นฐาน
ฉบับร่าง
⬇️ คำตอบจาก blog.site ที่มอบสิทธิ์
Accept-CH: Sec-CH-UA-Model
Permissions-Policy: ch-ua-model=(self "https://cdn.site")
⬆️ คําขอทรัพยากรย่อยใน cdn.site มีคําแนะนําที่ได้รับมอบสิทธิ์
Sec-CH-UA-Model: "Pixel 5"
คุณสามารถระบุคำใบ้ได้หลายรายการสำหรับต้นทางหลายแห่ง ไม่ใช่แค่จากช่วง ch-ua ดังนี้
⬇️ คำตอบจาก blog.site ที่มอบสิทธิ์คำแนะนำหลายรายการให้กับหลายต้นทาง
Accept-CH: Sec-CH-UA-Model, DPR
Permissions-Policy: ch-ua-model=(self "https://cdn.site"),
ch-dpr=(self "https://cdn.site" "https://img.site")
กลยุทธ์: การมอบสิทธิ์ให้ iframe
iframe แบบข้ามต้นทางทำงานในลักษณะเดียวกับทรัพยากรแบบข้ามต้นทาง แต่คุณ
ให้ระบุคำใบ้ที่ต้องการมอบสิทธิ์ในแอตทริบิวต์ allow
⬇️ คำตอบจาก blog.site
Accept-CH: Sec-CH-UA-Model
↪️ HTML สำหรับ blog.site
<iframe src="https://widget.site" allow="ch-ua-model"></iframe>
⬆️ คําขอไปยัง widget.site
Sec-CH-UA-Model: "Pixel 5"
แอตทริบิวต์ allow ใน iframe จะลบล้างส่วนหัว Accept-CH ที่
widget.site อาจส่งตัวเอง ดังนั้นโปรดตรวจสอบว่าคุณได้ระบุทุกอย่าง
ในเว็บไซต์ iframe
กลยุทธ์: คำแนะนำฝั่งเซิร์ฟเวอร์แบบไดนามิก
หากคุณมีส่วนที่เฉพาะเจาะจงในเส้นทางของผู้ใช้ซึ่งจําเป็นต้องใช้ตัวเลือกมากขึ้น คำแนะนำอื่นๆ มากกว่าส่วนอื่นๆ ของไซต์ คุณอาจ เลือกที่จะขอคำแนะนำเหล่านั้น ตามความต้องการ มากกว่าแค่แบบคงที่ กรณีนี้ซับซ้อนกว่าสำหรับ จัดการ แต่ถ้าคุณตั้งค่าส่วนหัวแยกสำหรับแต่ละเส้นทางไว้แล้ว เป็นไปได้
สิ่งสำคัญที่ควรจำไว้คือ Accept-CH แต่ละรายการ
จะเป็นการเขียนทับชุดที่มีอยู่แล้ว ดังนั้น หากคุณมีการเปลี่ยนแปลง
ตั้งค่าส่วนหัว แต่ละหน้าจะต้องขอคำใบ้ครบชุดที่จำเป็น
ตัวอย่างเช่น คุณอาจมี 1 ส่วนบนเว็บไซต์ที่คุณต้องการให้แสดง
ไอคอนและการควบคุมที่ตรงกับระบบปฏิบัติการของผู้ใช้ ในกรณีนี้ คุณอาจ
ต้องการดึงข้อมูล Sec-CH-UA-Platform-Version เพิ่มเติมเพื่อแสดงตามความเหมาะสม
ทรัพยากรย่อย
⬇️ ส่วนหัวการตอบกลับสำหรับ /blog
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA
⬇️ ส่วนหัวการตอบกลับสำหรับ /app
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA
กลยุทธ์: ต้องมีคำแนะนำฝั่งเซิร์ฟเวอร์ในคำขอแรก
อาจมีบางกรณีที่คุณต้องการคำแนะนำมากกว่าชุดเริ่มต้นของคำแนะนำ คำขอแรก แต่มักจะเกิดขึ้นไม่บ่อยนัก ดังนั้นโปรดตรวจสอบ ได้ตรวจสอบเหตุผลแล้ว
คำขอแรกหมายถึงคำขอระดับบนสุดรายการแรกสำหรับต้นทางนั้นจริงๆ ที่ส่งในเซสชันการเรียกดูนั้น ชุดคำแนะนำเริ่มต้นประกอบด้วยเบราว์เซอร์ พร้อมเวอร์ชันหลัก แพลตฟอร์ม และตัวบ่งชี้อุปกรณ์เคลื่อนที่ ดังนั้น คำถาม คุณต้องการข้อมูลเพิ่มเติมในการโหลดหน้าเว็บเริ่มต้นหรือไม่
คําแนะนําเพิ่มเติมเกี่ยวกับคําขอแรกจะมี 2 ตัวเลือก อย่างแรก คุณสามารถ
ใช้ประโยชน์จากส่วนหัว Critical-CH ซึ่งใช้รูปแบบเดียวกับ Accept-CH
แต่จะแจ้งให้เบราว์เซอร์ทราบว่าควรลองส่งคำขออีกครั้งทันทีหาก
ข้อความ 1 รายการถูกส่งโดยไม่มีคำแนะนำที่สำคัญ
⬆️ คำขอเริ่มต้น
[With default headers]
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Model
🔃 เบราว์เซอร์ลองส่งคำขอเริ่มต้นอีกครั้งโดยมีส่วนหัวเพิ่มเติม
[With default headers + …]
Sec-CH-UA-Model: Pixel 5
ซึ่งจะมีค่าใช้จ่ายในการดำเนินการซ้ำในคำขอแรก แต่ ต้นทุนในการติดตั้งใช้งานค่อนข้างต่ำ ส่งส่วนหัวเพิ่มเติมและเบราว์เซอร์ จะจัดการที่เหลือเอง
สำหรับสถานการณ์ที่คุณต้องการ คุณจำเป็นต้องมีคำแนะนำเพิ่มเติมเกี่ยวกับ การโหลดหน้าเว็บความน่าเชื่อถือของคำแนะนำไคลเอ็นต์ ข้อเสนอ กำลังกำหนดเส้นทางเพื่อระบุคำแนะนำในการตั้งค่าระดับการเชื่อมต่อ ช่วงเวลานี้ ใช้ประโยชน์จาก Application-Layer Protocol ส่วนขยายการตั้งค่า(ALPS) เป็น TLS 1.3 เพื่อเปิดใช้การส่งคำแนะนำล่วงหน้าในการเชื่อมต่อ HTTP/2 และ HTTP/3 ช่วงเวลานี้ ยังคงอยู่ในระยะเริ่มต้น แต่ถ้าคุณจัดการ TLS ของตนเองและ การเชื่อมต่ออินเทอร์เน็ตของคุณ นี่จึงเป็นเวลาที่เหมาะสมในการมีส่วนร่วม
กลยุทธ์: การสนับสนุนเดิม
คุณอาจมีโค้ดเดิมหรือโค้ดของบุคคลที่สามในเว็บไซต์ที่ขึ้นอยู่กับ
navigator.userAgent รวมถึงบางส่วนของสตริง User Agent ที่จะ
ที่ลดลง ในระยะยาวคุณควรวางแผนที่จะเปลี่ยนไปใช้แบรนด์ที่เทียบเท่า
navigator.userAgentData การโทร แต่มีวิธีแก้ปัญหาชั่วคราว
รีโทรฟิล UA-CH เป็น
ไลบรารีที่อนุญาตให้คุณเขียนทับ navigator.userAgent ด้วยสตริงใหม่
สร้างจากค่า navigator.userAgentData ที่ขอ
ตัวอย่างเช่น โค้ดนี้จะสร้างสตริง User Agent นอกจากนี้ มี "model" คำใบ้:
import { overrideUserAgentUsingClientHints } from './uach-retrofill.js';
overrideUserAgentUsingClientHints(['model'])
.then(() => { console.log(navigator.userAgent); });
สตริงผลลัพธ์จะแสดงรูปแบบ Pixel 5 แต่ยังคงแสดงรูปแบบที่ลดลง
92.0.0.0 เนื่องจากไม่มีการขอคำแนะนำuaFullVersion:
Mozilla/5.0 (Linux; Android 10.0; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.0.0 Mobile Safari/537.36
การสนับสนุนเพิ่มเติม
หากกลยุทธ์เหล่านี้ไม่ครอบคลุมกรณีการใช้งานของคุณ โปรดเริ่มต้นพูดคุยใน privacy-sandbox-dev-support ที่เก็บ เพื่อให้เราสำรวจปัญหาของคุณร่วมกัน
ภาพโดย Ricardo โรชา ใน Unแยกต่างหาก