Próbna wersja obsługi nagłówka HTTP w Storage Access

Natalia Markoborodova

W Chrome w wersji 130 rozpoczynamy testowanie interfejsu Storage Access API (SAA), który umożliwia dodawanie nagłówków HTTP: Storage Access Headers. Nowy nagłówek żądania Sec-Fetch-Storage-Access i nagłówek odpowiedzi Activate-Storage-Access mają na celu obsługę zasobów innych niż ramki iframe oraz poprawę wydajności i wygody użytkowników w przypadku witryn, które korzystają z treści osadzonych, takich jak widżety mediów społecznościowych, kalendarze i narzędzia interaktywne.

Przepływ JavaScriptu (i jego ograniczenia)

Wcześniej SAA wymagało wywołania interfejsu API JavaScript do document.requestStorageAccess() przy każdym ponownym wczytaniu, nawet jeśli użytkownik przyznał już uprawnienia. Ta metoda jest skuteczna, ale ma pewne ograniczenia:

• Wiele podróży w sieci: zanim osadzone treści zaczęły w pełni działać, proces często wymagał kilku żądań sieciowych i ponownego wczytania strony.
• Zależność od elementów iframe: wykonywanie kodu JavaScript wymagało użycia elementów iframe lub zasobów podrzędnych w elementach iframe, co ograniczało elastyczność deweloperów.

Jeśli np. widżet kalendarza z calendar.example jest umieszczony na stronie website.example przy użyciu tylko kodu JavaScript, będzie wyglądać tak:

1. Wczytaj element zastępczy: website.example wysyła żądanie widżetu. Widżet calendar.example umieszczony na stronie website.example nie ma dostępu do własnych plików cookie bez partycji, więc zamiast niego renderowany jest widżet zastępczy.
2. Poproś o uprawnienia: wczytuje się element zastępczy, a następnie wywołuje funkcję document.requestStorageAccess(), aby poprosić o uprawnienia storage-access.
3. Użytkownik wybiera opcję przyznania uprawnień.
4. Ponownie załaduj widżet: widżet odświeża się, tym razem z dostępem do plików cookie, i w końcu wczytuje spersonalizowane treści.
5. Za każdym razem, gdy użytkownik ponownie odwiedzi witrynę z osadzonym widżetem calendar.example, proces wygląda dokładnie tak samo jak w krokach 1, 2 i 4. Jedynym uproszczeniem jest to, że użytkownik nie musi ponownie przyznawać dostępu.

Ten proces jest nieefektywny: jeśli użytkownik przyznał już uprawnienia do przechowywania danych, początkowe wczytanie elementu iframe, wywołanie document.requestStorageAccess() i ponowne wczytanie stają się niepotrzebne i powodują opóźnienie.

Nowy proces z nagłówkami HTTP

Nowe nagłówki Storage Access umożliwiają wydajniejsze wczytywanie treści osadzonych, w tym zasobów innych niż iframe.

Dzięki nagłówkom Storage Access przeglądarka automatycznie pobierze zasoby z ustawionym nagłówkiem żądania Sec-Fetch-Storage-Access: inactive, jeśli użytkownik przyznał już uprawnienia. Ustawienie nagłówka żądania nie wymaga żadnych działań ze strony dewelopera. Serwer może odpowiedzieć nagłówkiem Activate-Storage-Access: retry; allowed-origin="<origin>", a przeglądarka ponowi żądanie z wymaganymi danymi logowania.

Nagłówek żądania

Sec-Fetch-Storage-Access: <access-status>

Gdy użytkownik odwiedza stronę, która zawiera treści z innych witryn, przeglądarka automatycznie dołącza nagłówek Sec-Fetch-Storage-Access do żądań wysyłanych do innych witryn, które mogą wymagać danych logowania (np. plików cookie). Ten nagłówek wskazuje stan uprawnień do dostępu do plików cookie w przypadku osadzenia. Oto jak interpretować jego wartości:

• none: osadzony element nie ma uprawnienia storage-access, a tym samym nie ma dostępu do niepodzielonych plików cookie.
• inactive: umieszczony element ma uprawnienie storage-access, ale nie zdecydował się na jego użycie. Osadzony element nie ma dostępu do niepodzielonych plików cookie.
• active: umieszczony element ma dostęp do niepodzielonych plików cookie. Ta wartość będzie uwzględniana w każdym żądaniu pochodzącym z innej domeny, które ma dostęp do niepodzielonych plików cookie.

Nagłówki odpowiedzi

Activate-Storage-Access: <retry-or-reload>

Nagłówek Activate-Storage-Access informuje przeglądarkę, czy ma ponowić próbę wysłania żądania z plikami cookie, czy wczytać zasób bezpośrednio z włączonym interfejsem Storage Access API. Nagłówek może mieć te wartości:

• load: nakazuje przeglądarce przyznanie osadzającemu dostęp do plików cookie bez partycji dla żądanego zasobu.
• retry: serwer odpowiada, że przeglądarka powinna aktywować uprawnienia dostępu do pamięci, a następnie ponowić próbę wysłania żądania.

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

Obsługa zasobów innych niż ramki iframe

Aktualizacja nagłówków Storage Access Headers umożliwia SAA w przypadku treści osadzonych w inny sposób niż w ramce iframe, np. obrazów hostowanych w innej domenie. Wcześniej żaden interfejs API platformy internetowej nie umożliwiał wczytywania takich zasobów z danymi logowania w przeglądarkach, jeśli pliki cookie innych firm były niedostępne. Na przykład embedding-site.example może poprosić o obraz:

   <img src="https://server.example/image"/>

Serwer może odpowiedzieć treścią lub błędem w zależności od tego, czy plik cookie jest dostępny:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

Jeśli plik cookie jest niedostępny, serwer sprawdza wartość nagłówka żądania Sec-Fetch-Storage-Access. Jeśli ta wartość jest ustawiona na inactive, serwer odpowiada nagłówkiem Activate-Storage-Access: retry, co oznacza, że żądanie należy ponowić z dostępem do pamięci. Jeśli nie ma pliku cookie, a nagłówek Sec-Fetch-Storage-Access nie ma wartości „inactive”, obraz się nie wczyta.

Przepływ nagłówka HTTP

Dzięki nagłówkom HTTP przeglądarka może rozpoznać, kiedy użytkownik przyznał już widżetowi uprawnienia dostępu do pamięci, i podczas kolejnych wizyt wczytać element iframe z dostępem do plików cookie bez partycji.

W przypadku nagłówków Storage Access kolejne wizyty na stronach będą wywoływać ten proces:

1. Użytkownik ponownie odwiedza stronę website.example, na której jest osadzony element calendar.example. Pobieranie nie ma jeszcze dostępu do pliku cookie, tak jak wcześniej. Użytkownik przyznał jednak wcześniej uprawnienie storage-access, a pobieranie zawiera nagłówek Sec-Fetch-Storage-Access: inactive, co oznacza, że dostęp do niepodzielonych plików cookie jest dostępny, ale nie jest używany.
2. Serwer calendar.example odpowiada nagłówkiem Activate-Storage-Access: retry; allowed-origin="<origin>" (w tym przypadku <origin> to https://website.example), aby wskazać, że pobranie zasobu wymaga użycia plików cookie bez partycji z uprawnieniami dostępu do pamięci.
3. Przeglądarka ponawia żądanie, tym razem uwzględniając niepodzielone pliki cookie (aktywując uprawnienie storage-access dla tego pobierania).
4. calendar.example Serwer odpowiada spersonalizowaną treścią elementu iframe. Odpowiedź zawiera nagłówek Activate-Storage-Access: load, który wskazuje, że przeglądarka powinna wczytać treść z aktywnym uprawnieniem storage-access (czyli wczytać z niepodzielonym dostępem do plików cookie, tak jakby wywołano document.requestStorageAccess()).
5. Klient użytkownika wczytuje zawartość elementu iframe z niepodzielonym dostępem do plików cookie za pomocą uprawnienia storage-access. Po wykonaniu tego kroku widżet będzie działać zgodnie z oczekiwaniami.

Aktualizowanie rozwiązania

W przypadku funkcji nagłówków dostępu do pamięci możesz zaktualizować kod w 2 przypadkach:

1. Używasz SAA i chcesz osiągać lepsze wyniki dzięki logice nagłówka.
2. Na serwerze masz weryfikację lub logikę, która zależy od tego, czy nagłówek Origin jest uwzględniony w żądaniu.

Implementowanie logiki nagłówków SAA

Aby używać w swoim rozwiązaniu nagłówków Storage Access Headers, musisz je zaktualizować. Załóżmy, że jesteś calendar.example właścicielem. Aby usługa website.example mogła wczytać spersonalizowany widżet calendar.example, kod widżetu musi mieć dostęp do pamięci.

Po stronie klienta

Funkcja nagłówków dostępu do pamięci nie wymaga aktualizacji kodu po stronie klienta w przypadku istniejących rozwiązań. Więcej informacji o wdrażaniu SAA znajdziesz w dokumentacji.

Po stronie serwera

Po stronie serwera możesz używać nowych nagłówków:

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Obejrzyj demo, aby zobaczyć, jak to rozwiązanie działa w praktyce.

Aktualizowanie logiki nagłówka Origin

Dzięki nagłówkom Storage Access Chrome wysyła nagłówek Origin w większej liczbie żądań niż wcześniej. Może to wpłynąć na logikę po stronie serwera, jeśli opiera się ona na tym, że nagłówek Origin jest obecny tylko w przypadku określonych typów żądań (np. zdefiniowanych przez CORS).

Aby uniknąć potencjalnych problemów, sprawdź kod po stronie serwera:

• Sprawdź, czy nie ma żadnych weryfikacji ani logiki, które zależą od obecności nagłówka Origin.
• Zaktualizuj kod, aby w większej liczbie przypadków obsługiwał nagłówek Origin.

Najważniejsze zalety

Nagłówki dostępu do pamięci masowej to zalecany, wydajniejszy sposób korzystania z SAA. Ta zmiana przynosi kilka ulepszeń:

• Obsługa osadzania w elementach innych niż iframe: umożliwia korzystanie z SAA w przypadku większej liczby zasobów.
• Mniejsze wykorzystanie sieci: mniej żądań i mniejsze pakiety danych.
• Mniejsze wykorzystanie procesora: mniejsze przetwarzanie JavaScriptu.
• Lepsze wrażenia użytkownika: eliminuje uciążliwe wczytywanie pośrednie.

Udział w eksperymencie

Wersje próbne origin pozwalają wypróbować nowe funkcje i przekazać opinię na temat ich użyteczności, praktyczności i skuteczności. Więcej informacji znajdziesz w artykule Pierwsze kroki z testami origin.

Możesz wypróbować funkcję nagłówków dostępu do pamięci, rejestrując się w programie testów origin od Chrome 130. Aby wziąć udział w testach origin trial:

1. Otwórz stronę rejestracji w programie testów Storage Access Headers.
2. Postępuj zgodnie z instrukcjami dotyczącymi udziału w testach origin trial.

Testowanie lokalne

Możesz przetestować funkcję nagłówków Storage Access lokalnie, aby upewnić się, że Twoja witryna jest gotowa na tę zmianę.

Aby skonfigurować instancję Chrome, wykonaj te czynności:

1. Włącz flagę Chrome na urządzeniu chrome://flags/#storage-access-headers.
2. Aby zmiany zaczęły obowiązywać, ponownie uruchom Chrome.

Angażowanie się i przesyłanie opinii

Jeśli masz uwagi lub napotkasz problemy, możesz zgłosić problem. Więcej informacji o nagłówkach dostępu do pamięci znajdziesz w wyjaśnieniu na GitHubie.