Kullanıcı Aracısı İstemci İpuçlarına Taşı

Sitenizi kullanıcı aracısı dizesinden yeni User-Agent İstemci İpuçları'na taşıma stratejileri.

Rowan Merewood'dan daha fazla içerik

Kullanıcı aracısı dizesi, tarayıcılarda önemli bir pasif dijital parmak izi oluşturur ve işlenmesi zordur. Bununla birlikte, kullanıcı aracısı verilerini toplamak ve işlemek için her türlü geçerli neden vardır. Bu nedenle, daha iyi bir çözüme giden yol olması gerekir. Kullanıcı Aracısı İstemci İpuçları, kullanıcı aracısı verilerine ihtiyacınızı beyan etmek ve bu verileri kullanımı kolay bir biçimde döndürmek için yöntemler sunar.

Bu makale, kullanıcı aracısı verilerine erişiminizi denetleme ve kullanıcı aracısı dizesi kullanımını Kullanıcı Aracısı İstemci İpuçları'na taşıma konusunda size yol gösterecektir.

Kullanıcı aracısı verilerinin toplanmasını ve kullanılmasını denetleyin

Tüm veri toplama biçimlerinde olduğu gibi, bu verileri neden topladığınızı her zaman anlamanız gerekir. Herhangi bir işlem yapıp yapmamanızdan bağımsız olarak ilk adım, kullanıcı aracısı verilerini nerede ve neden kullandığınızı anlamaktır.

Kullanıcı aracısı verilerinin kullanılıp kullanılmadığını veya nerede kullanıldığını bilmiyorsanız, navigator.userAgent kullanımı için ön uç kodunuzda, User-Agent HTTP üst bilgisi kullanımı için arka uç kodunuzda arama yapabilirsiniz. Ayrıca navigator.platform ve navigator.appVersion gibi kullanımdan kaldırılmış özelliklerin kullanımı için kullanıcı arabirimi kodunuzu da kontrol etmelisiniz.

İşlevsel bir açıdan, kodunuzda kaydettiğiniz veya işlediğiniz herhangi bir yeri düşünün:

  • Tarayıcı adı veya sürümü
  • İşletim sisteminin adı veya sürümü
  • Cihaz markası veya modeli
  • CPU türü, mimarisi veya bit hızı (örneğin, 64 bit)

Kullanıcı aracısını işlemek için bir üçüncü taraf kitaplığı veya hizmeti kullanıyor da olabilirsiniz. Bu durumda, bunların Kullanıcı Aracısı İstemci İpuçları'nı destekleyecek şekilde güncellenip güncellenmediğini kontrol edin.

Yalnızca temel kullanıcı aracısı verilerini mi kullanıyorsunuz?

Kullanıcı Aracısı İstemci İpuçları'nın varsayılan grubu şunları içerir:

Önerilen kullanıcı aracısı dizesinin kısaltılmış sürümü, bu temel bilgileri de geriye dönük olarak uyumlu bir şekilde korur. Örneğin, dizede Chrome/90.0.4430.85 yerine Chrome/90.0.0.0 bulunur.

Kullanıcı aracısı dizesini yalnızca tarayıcı adı, ana sürüm veya işletim sistemi için kontrol ediyorsanız kullanımdan kaldırma uyarıları görme olasılığınız yüksek olsa da kodunuz çalışmaya devam eder.

Kullanıcı Aracısı İstemci İpuçları'na geçiş yapabilirsiniz ve geçiş yapmanız gerekir ancak bunu engelleyen eski kodunuz veya kaynak kısıtlamalarınız olabilir. Kullanıcı aracısı dizesindeki bilgilerin geriye dönük olarak uyumlu bir şekilde azaltılması, mevcut kodun daha az ayrıntılı bilgi alması ve temel işlevselliği sürdürmesi için tasarlanmıştır.

Strateji: İsteğe bağlı istemci tarafı JavaScript API'si

Şu anda navigator.userAgent kullanıyorsanız kullanıcı aracısı dizesini ayrıştırmaya geri dönmeden önce navigator.userAgentData seçeneğini tercih etmeye geçmeniz gerekir.

if (navigator.userAgentData) {
  // use new hints
} else {
  // fall back to user-agent string parsing
}

Mobil veya masaüstü için kontrol ediyorsanız mobile boole değerini kullanın:

const isMobile = navigator.userAgentData.mobile;

userAgentData.brands, tarayıcının bu markalarla uyumluluğunu listeleyebildiği brand ve version özelliklerine sahip bir nesne dizisidir. Buna doğrudan bir dizi olarak erişebilir veya belirli bir girişin mevcut olup olmadığını kontrol etmek için bir some() çağrısı kullanmak isteyebilirsiniz:

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
}

Daha ayrıntılı, yüksek entropili kullanıcı aracısı değerlerinden birine ihtiyacınız varsa bunu belirtmeniz ve döndürülen Promise öğesinde sonucu kontrol etmeniz gerekir:

navigator.userAgentData.getHighEntropyValues(['model'])
  .then(ua => {
    // requested hints available as attributes
    const model = ua.model
  });

Sunucu tarafı işlemeden istemci taraflı işlemeye geçmek isterseniz de bu stratejiyi kullanmak isteyebilirsiniz. JavaScript API, HTTP istek başlıklarına erişim gerektirmediğinden kullanıcı aracısı değerleri herhangi bir noktada istenebilir.

Strateji: Statik sunucu tarafı üstbilgi

Sunucuda User-Agent istek başlığını kullanıyorsanız ve bu verilere yönelik ihtiyaçlarınız siteniz genelinde nispeten tutarlıysa, istediğiniz istemci ipuçlarını yanıtlarınızda statik bir küme olarak belirtebilirsiniz. Genellikle bunu tek bir yerde yapılandırmanız gerektiğinden, bu nispeten basit bir yaklaşımdır. Örneğin, zaten başlıkları, barındırma yapılandırmanızı veya siteniz için kullandığınız çerçevenin ya da platformun üst düzey yapılandırmasını eklediyseniz web sunucusu yapılandırmanızda olabilir.

Kullanıcı aracısı verilerine göre sunulan yanıtları dönüştürüyor veya özelleştiriyorsanız bu stratejiyi göz önünde bulundurun.

Tarayıcılar veya diğer istemciler, farklı varsayılan ipuçları sağlamayı seçebilir. Bu nedenle, genellikle varsayılan olarak sağlansa bile ihtiyacınız olan her şeyi belirtmek iyi bir uygulamadır.

Örneğin, Chrome'un mevcut varsayılanları şu şekilde gösterilir:

⬇️ Yanıt başlıkları

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

Yanıtlarda cihaz modelini de almak isterseniz şunu göndermeniz gerekir:

⬇️ Yanıt başlıkları

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA

Bunu sunucu tarafında işlerken, ilk olarak istenen Sec-CH-UA başlığının gönderilip gönderilmediğini kontrol etmeniz ve ardından kullanılabilir olmadığı durumlarda User-Agent üst bilgi ayrıştırmasına geri dönmeniz gerekir.

Strateji: Kaynaklar arası isteklere ipuçları için yetki verme

Kendi isteklerinde Kullanıcı Aracısı İstemci İpuçlarının gönderilmesini gerektiren kaynaklar arası veya siteler arası alt kaynaklar istiyorsanız bir İzin Politikası kullanarak istenen ipuçlarını açıkça belirtmeniz gerekir.

Örneğin, https://blog.site hizmetinin https://cdn.site üzerinde belirli bir cihaz için optimize edilmiş kaynaklar döndürebilen kaynaklar barındırdığını varsayalım. https://blog.site, Sec-CH-UA-Model ipucunu isteyebilir, ancak Permissions-Policy üst bilgisini kullanarak https://cdn.site öğesine açıkça yetki vermesi gerekir. Politika kontrollü ipuçlarının listesine İstemci İpuçları Altyapı taslağı bölümünden ulaşabilirsiniz.

⬇️ İpucu için yetki veren blog.site adlı kullanıcının yanıtı

Accept-CH: Sec-CH-UA-Model
Permissions-Policy: ch-ua-model=(self "https://cdn.site")

⬆️ cdn.site üzerindeki alt kaynaklara yapılan isteklerde yetki verilmiş ipucu bulunur

Sec-CH-UA-Model: "Pixel 5"

Yalnızca ch-ua aralığı için değil, birden çok kaynak için birden fazla ipucu belirtebilirsiniz:

⬇️ blog.site tarafından birden fazla kaynağa birden fazla ipucu için yetki veren yanıt

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

Strateji: İpuçları için iframe'lere yetki verme

Kaynaklar arası iframe'ler, kaynaklar arası kaynaklara benzer şekilde çalışır ancak allow özelliğinde yetkilendirmek istediğiniz ipuçlarını belirtirsiniz.

⬇️ blog.site adlı kullanıcının yanıtı

Accept-CH: Sec-CH-UA-Model

↪️ blog.site için HTML

<iframe src="https://widget.site" allow="ch-ua-model"></iframe>

⬆️ widget.site isteği

Sec-CH-UA-Model: "Pixel 5"

iframe'deki allow özelliği, widget.site tarafından gönderilen tüm Accept-CH üst bilgilerini geçersiz kılar. Bu nedenle, iframe'e sahip sitenin ihtiyaç duyacağı her şeyi belirttiğinizden emin olun.

Strateji: Dinamik sunucu tarafı ipuçları

Kullanıcı yolculuğunun, sitenin geri kalanına göre daha fazla ipucuna ihtiyaç duyduğunuz belirli bölümleri varsa sitenin tamamında sabit olarak değil, isteğe bağlı olarak bu ipuçlarını istemeyi seçebilirsiniz. Bunun yönetilmesi daha karmaşıktır, ancak zaten her rota için farklı başlıklar ayarladıysanız bunu yapmanız makul olabilir.

Burada unutulmaması gereken önemli nokta, her bir Accept-CH üst bilgisi örneğinin etkin bir şekilde mevcut grubun üzerine yazılacağıdır. Bu nedenle, başlığı dinamik olarak ayarlıyorsanız her sayfanın gerekli ipuçlarının tamamını istemesi gerekir.

Örneğin, sitenizde kullanıcının işletim sistemiyle eşleşen simgeler ve denetimler sağlamak istediğiniz bir bölüm olabilir. Bunun için uygun alt kaynaklar sunmak üzere Sec-CH-UA-Platform-Version öğesini de kullanabilirsiniz.

⬇️ /blog için yanıt başlıkları

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

⬇️ /app için yanıt başlıkları

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA

Strateji: İlk istekte sunucu tarafı ipuçları gerekir

İlk istekte varsayılan ipucundan daha fazlasına ihtiyaç duyduğunuz durumlar olabilir. Ancak bu durum nadiren nadiren yaşanır. Bu nedenle gerekçeleri incelediğinizden emin olun.

İlk istek, söz konusu kaynak için söz konusu göz atma oturumunda gönderilen ilk üst düzey istek anlamına gelir. Varsayılan ipucu grubu, ana sürümün yer aldığı tarayıcı adını, platformu ve mobil göstergesini içerir. Burada sormamız gereken soru şudur: İlk sayfa yüklemesinde genişletilmiş veriye ihtiyaç duyuyor musunuz?

İlk istekle ilgili ek ipuçları için iki seçenek vardır. İlk olarak, Critical-CH üst bilgisini kullanabilirsiniz. Bu dosya Accept-CH ile aynı biçimi alır ancak ilk istek kritik ipucu olmadan gönderilirse tarayıcıya isteği hemen yeniden denemesi gerektiğini bildirir.

⬆️ İlk istek

[With default headers]

⬇️ Yanıt başlıkları

Accept-CH: Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Model

🔃 Tarayıcı, ek başlıkla ilk isteği yeniden dener

[With default headers + …]
Sec-CH-UA-Model: Pixel 5

Bu, ilk istekteki yeniden deneme işleminin ek yüküne neden olur ancak uygulama maliyeti nispeten düşüktür. Ekstra üstbilgiyi gönderin, tarayıcı gerisini halleder.

İlk sayfa yüklemesinde gerçekten ek ipuçlarına ihtiyaç duyduğunuz durumlarda İstemci İpuçları Güvenilirliği teklifi, bağlantı düzeyi ayarlarında ipuçlarını belirtmek için bir yol göstermektedir. Bu işlev, HTTP/2 ve HTTP/3 bağlantılarında ipuçlarının erken geçirilmesini sağlamak için TLS 1.3'e yönelik Uygulama Katmanı Protokolü Ayarları(ALPS) uzantısından yararlanır. Henüz çok erken bir aşamada olsak da kendi TLS ve bağlantı ayarlarınızı aktif olarak yönetiyorsanız bu, katkı sağlamak için ideal bir zamandır.

Strateji: Eski destek

Sitenizde, kullanıcı aracısı dizesinin kısaltılacak bölümleri de dahil olmak üzere navigator.userAgent temelli eski veya üçüncü taraf kodu bulunabilir. Uzun vadede, eşdeğer navigator.userAgentData çağrılarına geçiş yapmayı planlamanız gerekir ancak geçici bir çözüm vardır.

UA-CH retro doldurması, istenen navigator.userAgentData değerlerinden oluşturulan yeni bir dizeyle navigator.userAgent öğesinin üzerine yazmanıza olanak tanıyan küçük bir kitaplıktır.

Örneğin, bu kod, ek olarak "model" ipucunu da içeren bir kullanıcı aracısı dizesi oluşturur:

import { overrideUserAgentUsingClientHints } from './uach-retrofill.js';
overrideUserAgentUsingClientHints(['model'])
  .then(() => { console.log(navigator.userAgent); });

Sonuçta elde edilen dize, Pixel 5 modelini gösterir ancak uaFullVersion ipucu istenmediği için azaltılmış 92.0.0.0 değerini göstermeye devam eder:

Mozilla/5.0 (Linux; Android 10.0; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.0.0 Mobile Safari/537.36

Daha fazla destek

Bu stratejiler kullanım alanınızı kapsamıyorsa lütfen privacy-sandbox-dev-support deposunda tartışma başlatın. Böylece sorununuzu birlikte inceleyebiliriz.

Fotoğrafçı: Ricardo Rocha Unsplash'ta