İlgili Web Sitesi Grupları: geliştirici kılavuzu

İlişkili Websitesi Grupları (RWS), tarayıcıların bir alan grubu arasındaki ilişkileri anlamasına yardımcı olan bir web platformu mekanizmasıdır. Bu sayede tarayıcılar, belirli site işlevlerini etkinleştirmek için önemli kararlar alabilir (ör. siteler arası çerezlere erişime izin verilip verilmeyeceği) ve bu bilgileri kullanıcılara sunabilir.

Birçok site, tek bir kullanıcı deneyimi sunmak için birden fazla alandan yararlanır. Kuruluşlar, birden fazla kullanım alanı için farklı üst düzey alan adları (ör. ülkeye özgü alanlar veya resim ya da video barındırmak için hizmet alanları) kullanmak isteyebilir. İlişkili Websitesi Grupları, sitelerin belirli kontrollerle alanlar arasında veri paylaşmasına olanak tanır.

Genel hatlarıyla, İlişkili Websitesi Grubu, tek bir "grup birincil" ve potansiyel olarak birden fazla "grup üyesi"nin bulunduğu bir alan koleksiyonudur.

Aşağıdaki örnekte, primary birincil alanı, associatedSites ise ilişkili alt kümenin şartlarını karşılayan alanları listeler.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

İlgili web sitesi grupları, GitHub'da barındırılan herkese açık bir JSON dosyasında listelenir. Bu, onaylanan tüm grupların standart kaynağıdır. Tarayıcı, sitelerin aynı İlişkili Web Sitesi Grubu'na ait olup olmadığını belirlemek için bu dosyayı kullanır.

Yalnızca bir alan üzerinde yönetim kontrolüne sahip olan kullanıcılar bu alanla bir grup oluşturabilir. Gönderenlerin, her "set üyesi" ile "set birincil"i arasındaki ilişkiyi belirtmesi gerekir. Küme üyeleri, çeşitli alan türlerini içerebilir ve kullanım alanına dayalı bir alt kümenin parçası olmalıdır.

Uygulamanız, aynı İlişkili Web Sitesi Grubu'ndaki siteler arasında siteler arası çerezlere (üçüncü taraf çerezleri olarak da bilinir) erişime ihtiyaç duyuyorsa bu çerezlere erişim isteğinde bulunmak için Storage Access API (SAA) ve requestStorageAccessFor API'yi kullanabilirsiniz. Tarayıcı, her sitenin parçası olduğu alt kümeye bağlı olarak isteği farklı şekilde işleyebilir.

Set gönderme süreci ve koşulları hakkında daha fazla bilgi edinmek için gönderim yönergelerine göz atın. Gönderilen setler, gönderimlerin doğrulanması için çeşitli teknik kontrollerden geçer.

İlişkili web sitesi grupları, bir kuruluşun farklı üst düzey sitelerde ortak kimlik biçimine ihtiyaç duyduğu durumlarda iyi bir seçimdir.

İlişkili Web Sitesi Gruplarının kullanım alanlarından bazıları şunlardır:

  • Ülke özelleştirme. Ortak altyapıdan yararlanırken yerelleştirilmiş sitelerden yararlanma (example.co.uk, example.ca tarafından barındırılan bir hizmetten yararlanabilir).
  • Hizmet alanı entegrasyonu. Kullanıcıların hiçbir zaman doğrudan etkileşimde bulunmadığı ancak aynı kuruluşun sitelerinde hizmet sağlayan hizmet alanlarından yararlanma (example-cdn.com).
  • Kullanıcı içeriğinin ayrılması. Güvenlik nedeniyle kullanıcı tarafından yüklenen içeriği diğer site içeriklerinden ayıran farklı alanlardaki verilere erişme ve korumalı alan adının kimlik doğrulama (ve diğer) çerezlerine erişmesine izin verme. Kullanıcı tarafından yüklenen ve etkin olmayan içerikler sunuyorsanız en iyi uygulamaları uygulayarak bu içerikleri aynı alanda güvenli bir şekilde barındırabilirsiniz.
    • Kimliği doğrulanmış yerleştirilmiş içerik. Satış ortağı mülklerinden yerleştirilmiş içerikleri destekleme (üst düzey sitede oturum açmış kullanıcıya kısıtlanmış videolar, dokümanlar veya kaynaklar).
  • Oturum açın. Satış ortağı mülklerinde oturum açmayı destekleme FedCM API de bazı kullanım alanları için uygun olabilir.
  • Analytics. Hizmetlerin kalitesini artırmak için bağlı mülklerde kullanıcı yolculuklarının analizini ve ölçümünü dağıtma

İlişkili Websitesi Grupları entegrasyon ayrıntıları

Storage Access API

Browser Support

  • Chrome: 119.
  • Edge: 85.
  • Firefox: 65.
  • Safari: 11.1.

Source

Storage Access API (SAA), yerleştirilmiş kaynakta farklı içeriklerin normalde yalnızca birinci taraf bağlamında erişebileceği depolama alanına erişmesi için bir yol sağlar.

Yerleştirilmiş kaynaklar, depolama alanına şu anda erişip erişemediklerini kontrol etmek ve kullanıcı aracısından erişim isteğinde bulunmak için SAA yöntemlerini kullanabilir.

Üçüncü taraf çerezleri engellenirken İlişkili Web Sitesi Grupları (RWS) etkinleştirildiğinde Chrome, RWS içi bağlamlarda otomatik olarak izin verir ve aksi takdirde kullanıcıya bir istem gösterir. ("Bağlı web siteleri içi bağlam", yerleştirilmiş site ve üst düzey sitenin aynı bağlı web sitesinde olduğu bir iframe gibi bir bağlamdır.)

Depolama alanı erişimini kontrol etme ve isteme

Yerleştirilmiş siteler, depolama alanına şu anda erişip erişemediklerini kontrol etmek için Document.hasStorageAccess() yöntemini kullanabilir.

Yöntem, dokümanın çerezlerine erişip erişemediğini belirten bir boole değeriyle çözülen bir söz döndürür. Taahhüt, iframe üst çerçeveyle aynı kaynaktaysa da true değerini döndürür.

Yerleştirilmiş siteler, siteler arası bağlamda çerezlere erişim isteğinde bulunmak için Document.requestStorageAccess() (rSA) kullanabilir.

requestStorageAccess() API'sinin bir iFrame içinden çağrılması gerekir. Bu iframe'in kısa süre önce kullanıcı etkileşimi (tüm tarayıcılar tarafından zorunlu tutulan bir kullanıcı hareketi) almış olması gerekir. Ancak Chrome, kullanıcının son 30 gün içinde bir noktada bu iframe'in sahibi olan siteyi ziyaret etmesini ve özellikle de iframe içinde değil, üst düzey bir doküman olarak bu siteyle etkileşime geçmesini de zorunlu kılar.

requestStorageAccess(), depolama alanına erişim izninin verilip verilmediğini çözen bir promise döndürür. Erişim herhangi bir nedenle reddedilirse söz, gerekçesi belirtilmek üzere reddedilir.

Chrome'da requestStorageAccessFor

Browser Support

  • Chrome: 119.
  • Edge: 119.
  • Firefox: not supported.
  • Safari: not supported.

Source

Storage Access API, yalnızca yerleştirilmiş sitelerin kullanıcı etkileşimi alan <iframe> öğelerinden depolama alanına erişim istemesine izin verir.

Bu durum, siteler arası resimler veya çerez gerektiren komut dosyası etiketleri kullanan üst düzey siteler için Storage Access API'yi kullanma konusunda zorluklar oluşturur.

Chrome bu sorunu gidermek için üst düzey sitelerin Document.requestStorageAccessFor() (rSAFor) ile belirli kaynaklar adına depolama alanı erişimi istemesini sağlayan bir yöntem uyguladı.

 document.requestStorageAccessFor('https://target.site')

requestStorageAccessFor() API'sinin üst düzey bir doküman tarafından çağrılması amaçlanmıştır. Bu belgede de kısa süre önce kullanıcı etkileşimi alınmış olmalıdır. Ancak Chrome, requestStorageAccess()'ün aksine, kullanıcı zaten sayfadayken üst düzey bir belgede son 30 gün içinde etkileşim olup olmadığını kontrol etmez.

Depolama alanı erişim izinlerini kontrol etme

Kamera veya coğrafi konum gibi bazı tarayıcı özelliklerine erişim, kullanıcı tarafından verilen izinlere bağlıdır. Permissions API, bir API'ye erişme izninin durumunu (izin verilip verilmediğini veya bir istemi tıklama ya da sayfayla etkileşim kurma gibi bir tür kullanıcı etkileşimi gerektirip gerektirmediğini) kontrol etmenin bir yolunu sağlar.

İzin durumunu navigator.permissions.query() kullanarak sorgulayabilirsiniz.

Mevcut bağlam için depolama alanı erişim iznini kontrol etmek üzere 'storage-access' dizesini iletmeniz gerekir:

navigator.permissions.query({name: 'storage-access'})

Belirtilen bir kaynağın depolama alanı erişim iznini kontrol etmek için 'top-level-storage-access' dizesini iletmeniz gerekir:

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

Yerleştirilmiş kaynağın bütünlüğünü korumak için bu işlemin yalnızca document.requestStorageAccessFor kullanılarak üst düzey belge tarafından verilen izinleri kontrol ettiğini unutmayın.

İznin otomatik olarak verilip verilemeyeceğine veya kullanıcı hareketi gerektirip gerektirmediğine bağlı olarak prompt veya granted döndürülür.

Kare başına model

rSA izinleri çerçeve başına geçerlidir. rSA ve rSAFor izinleri ayrı izinler olarak değerlendirilir.

Her yeni çerçevenin depolama erişimi için ayrı ayrı istek göndermesi gerekir ve erişim otomatik olarak verilir. Yalnızca ilk istek için kullanıcı hareketi gerekir. Gezinme veya alt kaynaklar gibi iframe tarafından başlatılan sonraki isteklerin kullanıcı hareketi beklemesi gerekmez. Bu, ilk istek tarafından tarama oturumu için verilir.

IFrame'in yenilenmesi, yeniden yüklenmesi veya başka bir şekilde yeniden oluşturulması için tekrar erişim isteğinde bulunulması gerekir.

Çerezler hem SameSite=None hem de Secure özelliklerini belirtmelidir. rSA yalnızca siteler arası bağlamlarda kullanılmak üzere işaretlenmiş çerezlere erişim sağlar.

SameSite=Lax, SameSite=Strict veya SameSite özelliğine sahip çerezler yalnızca birinci taraf kullanımı içindir ve rSA'dan bağımsız olarak siteler arası bağlamda asla paylaşılmaz.

Güvenlik

rSAFor için alt kaynak isteklerinde, kaynakların Merkezler Arası Kaynak Paylaşımı (CORS) üst bilgilerine veya crossorigin özelliğine sahip olması gerekir. Bu, açık bir şekilde etkinleştirmeyi sağlar.

Uygulama örnekleri

Kaynaklar arası yerleştirilmiş bir iframe'den depolama alanına erişim isteğinde bulunma

Üst düzey bir sitede yerleşik bir siteyi gösteren şema
requestStorageAccess()'ı başka bir sitedeki yerleşik bir içerikte kullanma

Depolama alanına erişiminiz olup olmadığını kontrol etme

Depolama alanına erişiminizin olup olmadığını kontrol etmek için document.hasStorageAccess() simgesini kullanın.

Sözleşme doğru olarak çözülürse siteler arası bağlamda depolamaya erişebilirsiniz. Sonuç yanlışsa depolama alanına erişim isteğinde bulunmanız gerekir.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

Depolama alanı erişimi isteğinde bulunma

Depolama alanı erişimi istemeniz gerekiyorsa önce depolama alanı erişim iznini navigator.permissions.query({name: 'storage-access'}) kontrol ederek kullanıcı hareketi gerektirip gerektirmediğini veya otomatik olarak verilip verilemeyeceğini öğrenin.

İzin granted ise document.requestStorageAccess() işlevini çağırabilirsiniz ve bu işlem kullanıcı hareketi olmadan başarılı olur.

İzin durumu prompt ise document.requestStorageAccess() aramasını, kullanıcı hareketinden (ör. düğme tıklaması) sonra başlatmanız gerekir.

Örnek:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Çerçeve, gezinme veya alt kaynaklardan gelen sonraki isteklerin siteler arası çerezlere erişme izni otomatik olarak olur. hasStorageAccess() true döndürür ve aynı İlgili Web Sitesi Grubu'ndaki siteler arası çerezler, ek JavaScript çağrıları olmadan bu isteklerde gönderilir.

Kaynaklar arası siteler adına çerez erişimi isteyen üst düzey siteler

requestStorageAccessFor() işlevinin bir yerleşim içinde değil, üst düzey bir sitede kullanıldığını gösteren şema
Farklı bir kaynak için üst düzey bir sitede requestStorageAccessFor() kullanma

Üst düzey siteler, belirli kaynakların adına depolama alanı erişimi istemek için requestStorageAccessFor()'ü kullanabilir.

hasStorageAccess() yalnızca kendisini çağıran sitenin depolama erişimi olup olmadığını kontrol eder. Bu nedenle, üst düzey bir site başka bir kaynağın izinlerini kontrol edebilir.

Kullanıcıdan istemde bulunup bulunulmayacağını veya depolama alanı erişiminin belirtilen kaynağa önceden verilip verilmediğini öğrenmek için navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) işlevini çağırın.

İzin granted ise document.requestStorageAccessFor('https://target.site') işlevini çağırabilirsiniz. Kullanıcı hareketi olmadan başarılı olmalıdır.

İzin prompt ise document.requestStorageAccessFor('https://target.site') çağrısını kullanıcı hareketinin (ör. düğme tıklaması) arkasına bağlamanız gerekir.

Örnek:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Başarılı bir requestStorageAccessFor() çağrısından sonra, siteler arası istekler CORS veya crossorigin özelliğini içeriyorsa çerezleri içerir. Bu nedenle, siteler bir isteği tetiklemeden önce beklemek isteyebilir.

İstekler credentials: 'include' seçeneğini kullanmalı ve kaynaklar crossorigin="use-credentials" özelliğini içermelidir.

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

Yerel olarak test etme

Ön koşullar

İlgili web sitesi gruplarını yerel olarak test etmek için komut satırından başlatılan Chrome 119 veya sonraki bir sürümü kullanın ve test-third-party-cookie-phaseout Chrome işaretini etkinleştirin.

Chrome işaretini etkinleştirme

Gerekli Chrome işaretini etkinleştirmek için adres çubuğundan chrome://flags#test-third-party-cookie-phaseout adresine gidin ve işareti Enabled olarak değiştirin. İşaretler değiştirildikten sonra tarayıcıyı yeniden başlattığınızdan emin olun.

Chrome'u yerel bir İlişkili Websitesi Grubu ile başlatma

Chrome'u yerel olarak tanımlanmış İlgili Web Sitesi Kümesi ile başlatmak için bir kümenin üyeleri olan URL'leri içeren bir JSON nesnesi oluşturun ve bu nesneyi --use-related-website-set parametresine iletin.

Chromium'u işaretlerle çalıştırma hakkında daha fazla bilgi edinin.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Örnek

İlgili Web Sitesi Grupları'nı yerel olarak etkinleştirmek için chrome://flags'te test-third-party-cookie-phaseout'ü etkinleştirmeniz ve Chrome'u, bir grubun üyesi olan URL'leri içeren JSON nesnesi ile birlikte --use-related-website-set işaretiyle komut satırından başlatmanız gerekir.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Siteler arası çerezlere erişiminiz olduğunu doğrulama

Test edilen sitelerden API'leri (rSA veya rSAFor) çağırın ve siteler arası çerezlere erişimi doğrulayın.

İlişkili Websitesi Grupları gönderim süreci

Alanlar arasındaki ilişkiyi beyan etmek ve hangi alt kümenin parçası olduklarını belirtmek için aşağıdaki adımları uygulayın.

1. RWS'nizi tanımlama

İlişkili Websitesi Grubu'nun parçası olacak set birincil ve set üyeleri dahil olmak üzere ilgili alanları tanımlayın. Ayrıca her bir küme üyesinin hangi alt küme türüne ait olduğunu da belirleyin.

2. RWS gönderiminizi oluşturun

GitHub deposunun yerel bir kopyasını (klon veya çatal) oluşturun. Yeni bir dalda, related_website_sets.JSON dosyasında kümenizi yansıtacak değişiklikler yapın. Grubunuzun doğru JSON biçimlendirmesine ve yapısına sahip olduğundan emin olmak için JSON Oluşturucu Aracı'nı kullanabilirsiniz.

3. RWS'nizin teknik koşulları karşıladığından emin olun

Set oluşturma koşullarının ve set doğrulama koşullarının karşılandığından emin olun.

4. RWS'nizi yerel olarak test etme

Setinizi göndermek için bir alma isteği (PR) oluşturmadan önce, gerekli tüm kontrolleri geçtiğinden emin olmak için gönderiminizi yerel olarak test edin.

5. Bağlı web sitelerinizi gönderme

Chrome'un standart İlişkili Websitesi Grubu listesini barındırdığı related_website_sets.JSON dosyasına PR oluşturarak İlişkili Websitesi Grubu'nu gönderin. (PR oluşturmak için GitHub hesabı gerekir ve listeye katkıda bulunabilmeniz için önce bir Katkıda Bulunan Lisans Sözleşmesi (CLA) imzalamanız gerekir.)

PR oluşturulduktan sonra, 3. adımdaki şartların karşılandığından emin olmak için bir dizi kontrol gerçekleştirilir (ör. PBM'yi imzaladığınızdan ve .well-known dosyasının geçerli olduğundan emin olun).

İşlem başarılı olursa PR, kontrollerin geçtiğini gösterir. Onaylanan PR'ler, haftada bir kez (Doğu Saati'ne göre Salı günleri saat 12:00'de) standart İlişkili Websitesi Grubu listesine manuel olarak birleştirilir. Kontrollerden herhangi biri başarısız olursa gönderen, GitHub'da PR hatası üzerinden bilgilendirilir. Gönderen, hataları düzeltebilir ve PR'yi güncelleyebilir. Bu durumda şunları göz önünde bulundurun:

  • PR başarısız olursa gönderimin neden başarısız olabileceğiyle ilgili ek bilgiler bir hata mesajında sağlanır. (example).
  • Set gönderimlerini yöneten tüm teknik kontroller GitHub'da yapılır. Bu nedenle, teknik kontrollerden kaynaklanan tüm gönderim hataları GitHub'da görüntülenebilir.

Kurumsal politikalar

Chrome'da kurumsal kullanıcıların ihtiyaçlarını karşılamak için iki politika vardır:

  • İlgili Web Sitesi Grupları ile entegrasyon yapamayan sistemler, RelatedWebsiteSetsEnabled politikasıyla Chrome'un tüm kurumsal örneklerinde İlgili Web Sitesi Grupları özelliğini devre dışı bırakabilir.
    • Bazı kurumsal sistemlerde, İlişkili Websitesi Grubu'ndaki alanlardan farklı, kaydedilebilir alanlara sahip yalnızca şirket içi siteler (ör. intranet) bulunur. Bu siteleri herkese açık olarak göstermeden İlişkili Websitesi Grubu'nun bir parçası olarak değerlendirmeleri gerekiyorsa (alanlar gizli olabileceğinden) herkese açık İlişkili Websitesi Grupları listelerini RelatedWebsiteSetsOverrides politikasıyla genişletebilir veya geçersiz kılabilirler.

Chrome, herkese açık ve Enterprise kümelerinin kesişim noktalarını replacements veya additions'ün belirtilip belirtilmediğine bağlı olarak iki şekilde çözer.

Örneğin, herkese açık {primary: A, associated: [B, C]} grubu için:

replacements setin sonu: {primary: C, associated: [D, E]}
Enterprise grubu, yeni bir grup oluşturmak için ortak siteyi emer.
Elde edilen kümeler: {primary: A, associated: [B]}
{primary: C, associated: [D, E]}
additions setin sonu: {primary: C, associated: [D, E]}
Herkese açık ve kurumsal gruplar birleştirilir.
Sonuç kümesi: {primary: C, associated: [A, B, D, E]}

İlişkili Web Sitesi Gruplarıyla ilgili sorunları giderme

"Kullanıcı istemi" ve "kullanıcı hareketi"

"Kullanıcı istemi" ve "kullanıcı hareketi" farklı şeylerdir. Chrome, aynı İlgili Web Sitesi Grubu'ndaki siteler için kullanıcılara izin istemi göstermez ancak yine de kullanıcının sayfayla etkileşime geçmesini gerektirir. Chrome, izin vermeden önce "kullanıcı etkileşimi" veya "kullanıcı etkinleştirme" olarak da adlandırılan bir kullanıcı hareketi gerektirir. Bunun nedeni, web platformu tasarım ilkeleri uyarınca Storage Access API'nin İlişkili Websitesi Grubu bağlamı dışında (yani requestStorageAccess()) kullanılması için de kullanıcı hareketi gerekmesidir.

Diğer sitelerin çerezlerine veya depolama alanlarına erişme

İlişkili Web Sitesi Grupları, farklı sitelerin depolama alanlarını birleştirmez. Yalnızca daha kolay (istemsiz) requestStorageAccess() çağrılarına olanak tanır. İlişkili Web Sitesi Grupları yalnızca Storage Access API'yi kullanmanın kullanıcılara verdiği zorluğu azaltır ancak erişim geri yüklendikten sonra ne yapılacağını belirlemez. A ve B aynı İlişkili Websitesi Grubu'ndaki farklı sitelerse ve A, B'yi yerleştiriyorsa B, requestStorageAccess()'yi çağırabilir ve kullanıcıdan istemde bulunmadan birinci taraf depolamaya erişebilir. İlişkili Websitesi Grupları, siteler arası iletişim gerçekleştirmez. Örneğin, İlişkili Web Sitesi Grubu oluşturmak, B'ye ait çerezlerin A'ya gönderilmeye başlamasına neden olmaz. Bu verileri paylaşmak istiyorsanız kendiniz paylaşmanız gerekir. Örneğin, B iframe'inden A çerçevesine bir window.postMessage göndererek.

İlişkili Websitesi Grupları, herhangi bir API çağırmadan bölümlendirilmemiş çerezlere erişime izin vermez. Siteler arası çerezler, grup içinde varsayılan olarak kullanıma sunulmaz. İlişkili Websitesi Grupları yalnızca gruptaki sitelerin Storage Access API izin istemlerini atlamasına olanak tanır. Bir iframe, çerezlerine erişmek istiyorsa document.requestStorageAccess() çağrısı yapmalıdır veya üst düzey sayfa document.requestStorageAccessFor() çağrısı yapabilir.

Geri bildirim

GitHub'da bir veri kümesi göndermek ve Storage Access API ile requestStorageAccessFor API'yi kullanmak, süreçle ilgili deneyiminizi ve karşılaştığınız sorunları paylaşabileceğiniz fırsatlardır.

İlişkili Web Sitesi Grupları ile ilgili tartışmalara katılmak için: