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. Nowe nagłówki żądania Sec-Fetch-Storage-Access i nagłówki odpowiedzi Activate-Storage-Access mają obsługiwać zasoby inne niż ramki iframe oraz zwiększać wydajność i komfort użytkowania stron internetowych, 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. Chociaż ta metoda jest skuteczna, 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żywania elementów iframe lub zasobów podrzędnych w elementach iframe, co ograniczało elastyczność programistó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 swoich 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 przyznanie 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ę, w której osadzony jest widżet 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 pamięci, początkowe wczytanie elementu iframe, wywołanie document.requestStorageAccess() i ponowne wczytanie stają się niepotrzebne i powodują opóźnienia.

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 pobiera 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 uwzględnia nagłówek Sec-Fetch-Storage-Access w żądaniach dotyczących 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. Interpretacja 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ę go używać. 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 ponownie wysłać żądanie 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ępu do plików cookie bez partycji w przypadku żą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ż iframe

Aktualizacja nagłówków dostępu do pamięci umożliwia SAA w przypadku treści osadzonych w inny sposób niż za pomocą elementu 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 pobieranie 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, korzystając z 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.

Wdrażanie 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ś właścicielem calendar.example. 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ń. Przeczytaj dokumentację, aby dowiedzieć się, jak wdrożyć SAA.

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 mieć wpływ na logikę po stronie serwera, jeśli opiera się ona na nagłówku Origin, który 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 nagłówek Origin był obecny w większej liczbie przypadków.

Najważniejsze zalety

Nagłówki dostępu do pamięci 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 rozmiary 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 umożliwiają wypróbowanie nowych funkcji i przekazanie opinii 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 źródła, który rozpocznie się w 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ć, uruchom ponownie Chrome.

Zaangażuj się i prześlij opinię

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.