שימוש בקובצי Cookie חתומים

בדף הזה מופיעה סקירה כללית של קובצי Cookie חתומים והוראות לשימוש בהם עם Cloud CDN. קובצי Cookie חתומים מאפשרים גישה למשאבים מוגבלת בזמן לקבוצה של קבצים, בין אם למשתמשים יש חשבונות Google ובין אם לא.

קובצי Cookie חתומים הם חלופה לכתובות URL חתומות. קובצי Cookie חתומים מגנים על הגישה כשלא ניתן לחתום בנפרד על עשרות או מאות כתובות URL לכל משתמש באפליקציה.

קובצי Cookie חתומים מאפשרים לכם:

• מאשרים למשתמש גישה ומספקים לו טוקן מוגבל בזמן לגישה לתוכן המוגן (במקום לחתום על כל כתובת URL).
• הגדרת היקף הגישה של המשתמש לתחילית ספציפית של כתובת URL, כמו https://media.example.com/videos/, והענקת גישה למשתמש המורשה לתוכן מוגן רק בתוך תחילית כתובת ה-URL הזו.
• כדאי להשאיר את כתובות ה-URL ואת מניפסטים המדיה ללא שינוי, כדי לפשט את תהליך יצירת החבילות ולשפר את האפשרות לשמירה במטמון.

אם אתם רוצים להגביל את הגישה לכתובות URL ספציפיות, כדאי להשתמש בכתובות URL חתומות.

לפני שמתחילים

לפני שמשתמשים בקובצי Cookie חתומים, צריך לבצע את הפעולות הבאות:

• מוודאים ש-Cloud CDN מופעל. הוראות מפורטות זמינות במאמר שימוש ב-Cloud CDN. אפשר להגדיר קובצי Cookie חתומים בקצה העורפי לפני שמפעילים את Cloud CDN, אבל ההגדרה לא משפיעה עד שמפעילים את Cloud CDN.

• אם צריך, מעדכנים לגרסה האחרונה של Google Cloud CLI:

  gcloud components update
  

סקירה כללית זמינה במאמר כתובות URL חתומות וקובצי Cookie חתומים.

הגדרת מפתחות של בקשות חתומות

כדי ליצור מפתחות לכתובות URL חתומות או לקובצי Cookie חתומים, צריך לבצע כמה שלבים שמתוארים בקטעים הבאים.

שיקולי אבטחה

חשוב: אתם צריכים להגדיר את שרתי האינטרנט של המקור כך שיאמתו את החתימות על כל בקשה חתומה שהם משרתים, ויקבלו או ידחו בקשות לא חתומות.

‫Cloud CDN לא מאמת בקשות בנסיבות הבאות:

• הבקשה לא חתומה.
• שירות לקצה העורפי או קטגוריית קצה עורפי של הבקשה לא מוגדרים עם Cloud CDN.

בקשות חתומות חייבות לעבור אימות במקור תמיד לפני הצגת התגובה. הסיבה לכך היא שאפשר להשתמש במקורות כדי להציג תערובת של תוכן חתום ולא חתום, ולקוח יכול לגשת למקור ישירות.

• ‫Cloud CDN לא חוסם בקשות ללא פרמטר שאילתה Signature או קובץ Cookie של HTTP‏ Cloud-CDN-Cookie. הוא דוחה בקשות עם פרמטרים לא תקינים (או עם פורמט שגוי).
• כשהאפליקציה מזהה חתימה לא חוקית, צריך לוודא שהיא מגיבה עם קוד תגובה HTTP 403 (Unauthorized). אי אפשר לשמור במטמון את קודי התגובה HTTP 403.
• התשובות לבקשות חתומות ולבקשות לא חתומות נשמרות במטמון בנפרד, כך שתשובה מוצלחת לבקשה חתומה ותקינה אף פעם לא משמשת להצגת בקשה לא חתומה.
• אם האפליקציה שולחת קוד תגובה שניתן לשמירה במטמון לבקשה לא חוקית, יכול להיות שבקשות עתידיות חוקיות יידחו בטעות.

במערכות עורפיות של Cloud Storage, חשוב להסיר את הגישה הציבורית כדי ש-Cloud Storage יוכל לדחות בקשות שחסר בהן חתימה תקפה.

בטבלה הבאה מפורט סיכום של ההתנהגות.

לבקשה יש חתימה	מציאה במטמון (cache hit)	התנהגות
לא	לא	העברה למקור העורפי.
לא	כן	הצגה מהמטמון.
כן	לא	אימות החתימה. אם התוקף מאומת, המערכת מעבירה את הבקשה למקור העורפי.
כן	כן	אימות החתימה. אם התוכן תקין, הוא יוגש מהמטמון.

יצירת מפתחות של בקשות חתומות

כדי להפעיל תמיכה בכתובות URL חתומות ובעוגיות חתומות של Cloud CDN, צריך ליצור מפתח אחד או יותר בשירות קצה עורפי, בקטגוריית קצה עורפי או בשניהם, שמופעל בהם Cloud CDN.

לכל שירות לקצה העורפי או קטגוריית קצה עורפי, אפשר ליצור ולמחוק מפתחות בהתאם לצרכי האבטחה. אפשר להגדיר עד שלושה מפתחות לכל קצה עורפי בכל פעם. מומלץ להחליף את המפתחות מדי פעם על ידי מחיקת המפתח הכי ישן, הוספת מפתח חדש ושימוש במפתח החדש כשחותמים על כתובות URL או קובצי Cookie.

אפשר להשתמש באותו שם מפתח בכמה שירותי קצה עורפיים ובכמה דליים של קצה עורפי, כי כל קבוצת מפתחות היא עצמאית. שמות של מפתחות יכולים להכיל עד 63 תווים. כדי לתת שם למפתחות, אפשר להשתמש בתווים A-Z,‏ a-z,‏ 0-9,‏ _ (קו תחתון) ו- (מקף).

כשיוצרים מפתחות, חשוב לשמור עליהם מאובטחים כי כל מי שיש לו אחד מהמפתחות יכול ליצור כתובות URL חתומות או קובצי Cookie חתומים ש-Cloud CDN מקבל עד שהמפתח נמחק מ-Cloud CDN. המפתחות מאוחסנים במחשב שבו יוצרים את כתובות ה-URL החתומות או קובצי ה-Cookie החתומים. בנוסף, Cloud CDN מאחסן את המפתחות כדי לאמת חתימות של בקשות.

כדי לשמור על סודיות המפתחות, ערכי המפתחות לא נכללים בתשובות לבקשות API. אם איבדתם מפתח, אתם צריכים ליצור מפתח חדש.

חשוב: צריך לשמור את קובץ המפתח שנוצר כפרטי, ולא לחשוף אותו למשתמשים או לאחסן אותו ישירות בקוד המקור. מומלץ להשתמש במנגנון לאחסון סודות, כמו Cloud Key Management Service, כדי להצפין את המפתח ולספק גישה רק לאפליקציות מהימנות.

כדי ליצור מפתח בקשה חתום, פועלים לפי השלבים הבאים.

המסוף

1. נכנסים לדף Cloud CDN במסוף Google Cloud .

   מעבר אל Cloud CDN

2. לוחצים על שם המקור שרוצים להוסיף לו את המפתח.
3. בדף פרטי המקור, לוחצים על הכפתור עריכה.
4. בקטע Origin basics (הגדרות בסיסיות של מקור), לוחצים על Next (הבא) כדי לפתוח את הקטע Host and path rules (כללים לגבי מארח ונתיב).
5. בקטע Host and path rules (כללים לגבי מארח ונתיב), לוחצים על Next (הבא) כדי לפתוח את הקטע Cache performance (ביצועים של מטמון).
6. בקטע תוכן מוגבל, בוחרים באפשרות Restrict access using signed URLs and signed cookies.

7. לוחצים על הוספת מפתח חתימה.

   1. מציינים שם ייחודי למפתח החתימה החדש.

   2. בקטע שיטת יצירת מפתח, בוחרים באפשרות יצירה אוטומטית. אפשר גם ללחוץ על Let me enter (אני רוצה להזין) ואז לציין ערך של מפתח חתימה.

      באפשרות הראשונה, מעתיקים את הערך של מפתח החתימה שנוצר באופן אוטומטי לקובץ פרטי, שבו אפשר להשתמש כדי ליצור כתובות URL חתומות.

   3. לוחצים על סיום.

   4. בקטע Cache entry maximum age (הגיל המקסימלי של רשומה במטמון), מזינים ערך ואז בוחרים יחידת זמן.

8. לוחצים על סיום.

gcloud

כלי שורת הפקודה gcloud קורא מפתחות מקובץ מקומי שאתם מציינים. צריך ליצור את קובץ המפתח על ידי יצירת 128 ביטים אקראיים חזקים, קידוד שלהם בפורמט Base64, ואז החלפת התו + ב-- והחלפת התו / ב-_. מידע נוסף זמין ב-RFC 4648. חשוב מאוד שהמפתח יהיה אקראי לחלוטין. במערכת כמו UNIX, אפשר ליצור מפתח אקראי חזק ולאחסן אותו בקובץ המפתח באמצעות הפקודה הבאה:

head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME

כדי להוסיף את המפתח לשירות לקצה העורפי:

gcloud compute backend-services \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

כדי להוסיף את המפתח לקטגוריית קצה עורפי:

gcloud compute backend-buckets \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

הערה: למרות שפקודת המשנה היא add-signed-url-key, המפתח הוא מפתח בקשה חתומה שפועל גם עבור קובצי Cookie חתומים וגם עבור כתובות URL חתומות.

הגדרת הרשאות ב-Cloud Storage

אם אתם משתמשים ב-Cloud Storage והגבלתם את האפשרות לקרוא את האובייקטים, עליכם להוסיף את חשבון השירות של Cloud CDN לרשימות ה-ACL של Cloud Storage כדי לתת ל-Cloud CDN הרשאה לקרוא את האובייקטים.

אין צורך ליצור את חשבון השירות. חשבון השירות נוצר באופן אוטומטי בפעם הראשונה שמוסיפים מפתח למאגר מידע של backend בפרויקט.

לפני שמריצים את הפקודה הבאה, צריך להוסיף לפחות מפתח אחד לקטגוריית קצה עורפי בפרויקט. אחרת, הפקודה תיכשל עם שגיאה כי חשבון השירות למילוי המטמון של Cloud CDN לא נוצר עד שמוסיפים מפתח אחד או יותר לפרויקט.

הערה: אם בפרויקט מוגדרת מדיניות ארגונית של שיתוף מוגבל לדומיין (DRS), צריך להשבית אותה לפני שמריצים את הפקודה gcloud storage buckets add-iam-policy-binding. חשוב להפעיל מחדש את המדיניות אחרי שמריצים את הפקודה gcloud storage buckets add-iam-policy-binding

.

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
  --member=serviceAccount:[e-mail] \
  --role=roles/storage.objectViewer

מחליפים את PROJECT_NUMBER במספר הפרויקט ואת BUCKET בקטגוריית האחסון.

חשבון השירות של Cloud CDN‏ [e-mail] לא מופיע ברשימת חשבונות השירות בפרויקט. הסיבה לכך היא שחשבון השירות של Cloud CDN הוא בבעלות Cloud CDN, ולא בבעלות הפרויקט שלכם.

מידע נוסף על מספרי פרויקטים זמין במאמר איתור מזהה הפרויקט ומספר הפרויקט במסמכי העזרה של מסוף Google Cloud .

התאמה אישית של זמן השהייה המקסימלי במטמון

מערכת Cloud CDN שומרת במטמון תגובות לבקשות חתומות, ללא קשר לכותרת Cache-Control של השרת העורפי. הזמן המקסימלי שבו אפשר לשמור תשובות במטמון בלי לבצע אימות מחדש מוגדר באמצעות הדגל signed-url-cache-max-age, שמוגדר כברירת מחדל לשעה אחת. אפשר לשנות את ההגדרה כמו שמוצג כאן.

כדי להגדיר את זמן השהייה המקסימלי במטמון לשירות לקצה העורפי או לקטגוריית קצה עורפי, מריצים אחת מהפקודות הבאות:

gcloud compute backend-services update BACKEND_NAME \
  --signed-url-cache-max-age MAX_AGE

gcloud compute backend-buckets update BACKEND_NAME \
  --signed-url-cache-max-age MAX_AGE

רשימה של שמות מפתחות של בקשות חתומות

כדי להציג את המפתחות בשירות לקצה העורפי או בקטגוריית קצה עורפי, מריצים אחת מהפקודות הבאות:

gcloud compute backend-services describe BACKEND_NAME

gcloud compute backend-buckets describe BACKEND_NAME

מחיקת מפתחות של בקשות חתומות

כדי שכתובות URL שנחתמו על ידי מפתח מסוים לא יכובדו יותר, מריצים אחת מהפקודות הבאות כדי למחוק את המפתח משירות הקצה העורפי או מקטגוריית הקצה העורפי:

gcloud compute backend-services \
   delete-signed-url-key BACKEND_NAME --key-name KEY_NAME

gcloud compute backend-buckets \
   delete-signed-url-key BACKEND_NAME --key-name KEY_NAME

יצירת מדיניות

מדיניות של קובצי Cookie חתומים היא סדרה של key-value זוגות (מופרדים באמצעות התו : ), בדומה לפרמטרים של שאילתה שמשמשים בכתובת URL חתומה. דוגמאות מופיעות במאמר בנושא הנפקת קובצי Cookie למשתמשים.

המדיניות מייצגת את הפרמטרים שבהם הבקשה תקפה. המדיניות נחתמת באמצעות קוד אימות הודעות (HMAC) מבוסס-גיבוב (hash), ש-Cloud CDN מאמת בכל בקשה.

הגדרת הפורמט והשדות של המדיניות

יש ארבעה שדות חובה שצריך להגדיר בסדר הבא:

• URLPrefix
• Expires
• KeyName
• Signature

בזוגות key-value במדיניות חתומה בנושא קובצי Cookie יש משמעות לשימוש באותיות רישיות.

URLPrefix

‫URLPrefix מציין קידומת של כתובת URL בקידוד Base64 בטוח לשימוש בכתובות URL, שכוללת את כל הנתיבים שהחתימה צריכה להיות תקפה לגביהם.

URLPrefix מקודד סכימה (http:// או https://), שם דומיין מלא (FQDN) ונתיב אופציונלי. הוספת / בסוף הנתיב היא אופציונלית אבל מומלצת. הקידומת לא צריכה לכלול פרמטרים של שאילתה או מקטעים כמו ? או #.

לדוגמה, https://media.example.com/videos מתאים לבקשות לשני המיקומים הבאים:

• https://media.example.com/videos?video_id=138183&user_id=138138
• https://media.example.com/videos/137138595?quality=low

הנתיב של הקידומת משמש כמחרוזת משנה של טקסט, ולא כנתיב של ספרייה. לדוגמה, הקידומת https://example.com/data מעניקה גישה לשני המיקומים הבאים:

• /data/file1
• /database

כדי להימנע מהטעות הזו, מומלץ לסיים את כל הקידומות ב-/, אלא אם אתם בוחרים בכוונה לסיים את הקידומת בשם קובץ חלקי כמו https://media.example.com/videos/123 כדי להעניק גישה ל:

• /videos/123_chunk1
• /videos/123_chunk2
• /videos/123_chunkN

אם כתובת ה-URL המבוקשת לא תואמת ל-URLPrefix, ‏ Cloud CDN דוחה את הבקשה ומחזיר ללקוח את השגיאה HTTP 403.

בתוקף עד

‫Expires חייב להיות חותמת זמן של יוניקס (מספר השניות מאז 1 בינואר 1970).

KeyName

‫KeyName הוא שם המפתח של מפתח שנוצר מול קטגוריית קצה עורפי או שירות לקצה העורפי. שמות המקשים הם תלויי-רישיות.

חתימה

‫Signature היא חתימת HMAC-SHA-1 בקידוד base64 בטוח לכתובות URL של השדות שמרכיבים את מדיניות קובצי ה-Cookie. האימות הזה מתבצע בכל בקשה. בקשות עם חתימה לא תקינה נדחות עם השגיאה HTTP 403.

יצירה של קובצי Cookie חתומים באופן פרוגרמטי

בדוגמאות הקוד הבאות אפשר לראות איך ליצור קובצי Cookie חתומים באופן פרוגרמטי.

הערה: מומלץ להשתמש ב-Secret Manager כדי לנהל את הגישה למפתחות החתימה.

הערה: רכיבי המארח והנתיב של URLPrefix משמשים לאימות החתימות. כשמספקים את URLPrefix לממשקי API פרוגרמטיים, צריך להשמיט את היציאה. במילים אחרות, אם הנתיב הוא https://example.com:443/path/, צריך לציין את הנתיב כ-https://example.com/path/. אחרת, החתימה שנוצרה לא תהיה זהה לערך שמחושב ב-Cloud CDN.

Go

import (
	"crypto/hmac"
	"crypto/sha1"
	"encoding/base64"
	"fmt"
	"io"
	"io/ioutil"
	"net/http"
	"os"
	"time"
)

// signCookie creates a signed cookie for an endpoint served by Cloud CDN.
//
// - urlPrefix must start with "https://" and should include the path prefix
// for which the cookie will authorize access to.
// - key should be in raw form (not base64url-encoded) which is
// 16-bytes long.
// - keyName must match a key added to the backend service or bucket.
func signCookie(urlPrefix, keyName string, key []byte, expiration time.Time) (string, error) {
	encodedURLPrefix := base64.URLEncoding.EncodeToString([]byte(urlPrefix))
	input := fmt.Sprintf("URLPrefix=%s:Expires=%d:KeyName=%s",
		encodedURLPrefix, expiration.Unix(), keyName)

	mac := hmac.New(sha1.New, key)
	mac.Write([]byte(input))
	sig := base64.URLEncoding.EncodeToString(mac.Sum(nil))

	signedValue := fmt.Sprintf("%s:Signature=%s",
		input,
		sig,
	)

	return signedValue, nil
}

Java

import java.net.MalformedURLException;
import java.net.URL;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.NoSuchAlgorithmException;
import java.time.ZonedDateTime;
import java.util.Base64;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class SignedCookies {

  public static void main(String[] args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.

    // The name of the signing key must match a key added to the back end bucket or service.
    String keyName = "YOUR-KEY-NAME";
    // Path to the URL signing key uploaded to the backend service/bucket.
    String keyPath = "/path/to/key";
    // The Unix timestamp that the signed URL expires.
    long expirationTime = ZonedDateTime.now().plusDays(1).toEpochSecond();
    // URL prefix to sign as a string. URL prefix must start with either "http://" or "https://"
    // and must not include query parameters.
    String urlPrefix = "https://media.example.com/videos/";

    // Read the key as a base64 url-safe encoded string, then convert to byte array.
    // Key used in signing must be in raw form (not base64url-encoded).
    String base64String = new String(Files.readAllBytes(Paths.get(keyPath)),
        StandardCharsets.UTF_8);
    byte[] keyBytes = Base64.getUrlDecoder().decode(base64String);

    // Create signed cookie from policy.
    String signedCookie = signCookie(urlPrefix, keyBytes, keyName, expirationTime);
    System.out.println(signedCookie);
  }

  // Creates a signed cookie for the specified policy.
  public static String signCookie(String urlPrefix, byte[] key, String keyName,
      long expirationTime)
      throws InvalidKeyException, NoSuchAlgorithmException {

    // Validate input URL prefix.
    try {
      URL validatedUrlPrefix = new URL(urlPrefix);
      if (!validatedUrlPrefix.getProtocol().startsWith("http")) {
        throw new IllegalArgumentException(
            "urlPrefix must start with either http:// or https://: " + urlPrefix);
      }
      if (validatedUrlPrefix.getQuery() != null) {
        throw new IllegalArgumentException("urlPrefix must not include query params: " + urlPrefix);
      }
    } catch (MalformedURLException e) {
      throw new IllegalArgumentException(
          "urlPrefix malformed: " + urlPrefix);
    }

    String encodedUrlPrefix = Base64.getUrlEncoder().encodeToString(urlPrefix.getBytes(
        StandardCharsets.UTF_8));
    String policyToSign = String.format("URLPrefix=%s:Expires=%d:KeyName=%s", encodedUrlPrefix,
        expirationTime, keyName);

    String signature = getSignatureForUrl(key, policyToSign);
    return String.format("Cloud-CDN-Cookie=%s:Signature=%s", policyToSign, signature);
  }

  // Creates signature for input string with private key.
  private static String getSignatureForUrl(byte[] privateKey, String input)
      throws InvalidKeyException, NoSuchAlgorithmException {

    final String algorithm = "HmacSHA1";
    final int offset = 0;
    Key key = new SecretKeySpec(privateKey, offset, privateKey.length, algorithm);
    Mac mac = Mac.getInstance(algorithm);
    mac.init(key);
    return Base64.getUrlEncoder()
        .encodeToString(mac.doFinal(input.getBytes(StandardCharsets.UTF_8)));
  }
}

Python

import argparse
import base64
from datetime import datetime, timezone
import hashlib
import hmac
from urllib.parse import parse_qs, urlsplit


def sign_cookie(
    url_prefix: str,
    key_name: str,
    base64_key: str,
    expiration_time: datetime,
) -> str:
    """Gets the Signed cookie value for the specified URL prefix and configuration.

    Args:
        url_prefix: URL prefix to sign.
        key_name: name of the signing key.
        base64_key: signing key as a base64 encoded string.
        expiration_time: expiration time as time-zone aware datetime.

    Returns:
        Returns the Cloud-CDN-Cookie value based on the specified configuration.
    """
    encoded_url_prefix = base64.urlsafe_b64encode(
        url_prefix.strip().encode("utf-8")
    ).decode("utf-8")
    epoch = datetime.fromtimestamp(0, timezone.utc)
    expiration_timestamp = int((expiration_time - epoch).total_seconds())
    decoded_key = base64.urlsafe_b64decode(base64_key)

    policy = f"URLPrefix={encoded_url_prefix}:Expires={expiration_timestamp}:KeyName={key_name}"

    digest = hmac.new(decoded_key, policy.encode("utf-8"), hashlib.sha1).digest()
    signature = base64.urlsafe_b64encode(digest).decode("utf-8")

    signed_policy = f"Cloud-CDN-Cookie={policy}:Signature={signature}"

    return signed_policy

אימות של קובצי Cookie חתומים

תהליך האימות של קובץ Cookie חתום זהה בעצם לתהליך של יצירת קובץ Cookie חתום. לדוגמה, נניח שרוצים לאמת את כותרת קובץ ה-Cookie החתומה הבאה:

Cookie: Cloud-CDN-Cookie=URLPrefix=URL_PREFIX:Expires=EXPIRATION:KeyName=KEY_NAME:Signature=SIGNATURE; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly

אתם יכולים להשתמש במפתח הסודי שנקרא KEY_NAME כדי ליצור באופן עצמאי את החתימה, ואז לוודא שהיא תואמת ל-SIGNATURE.

הנפקת קובצי Cookie למשתמשים

האפליקציה שלך צריכה ליצור ולהנפיק לכל משתמש (לקוח) קובץ Cookie יחיד של HTTP שמכיל מדיניות חתומה בצורה נכונה:

1. יוצרים חותם HMAC-SHA-1 בקוד האפליקציה.

2. חותמים על המדיניות באמצעות המפתח שנבחר, ורושמים את שם המפתח שהוספתם ל-backend, כמו mySigningKey.

3. יוצרים מדיניות בנושא קובצי Cookie בפורמט הבא, וחשוב לזכור שהשם והערך הם תלויי-רישיות:

   Name: Cloud-CDN-Cookie
   Value: URLPrefix=$BASE64URLECNODEDURLORPREFIX:Expires=$TIMESTAMP:KeyName=$KEYNAME:Signature=$BASE64URLENCODEDHMAC
   

   כותרת Set-Cookie לדוגמה:

   Set-Cookie: Cloud-CDN-Cookie=URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv:Expires=1566268009:KeyName=mySigningKey:Signature=0W2xlMlQykL2TG59UZnnHzkxoaw=; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
   

   המאפיינים Domain ו-Path בקובץ ה-Cookie קובעים אם הלקוח שולח את קובץ ה-Cookie ל-Cloud CDN.

המלצות ודרישות

• צריך להגדיר באופן מפורש את המאפיינים Domain ו-Path כך שיתאימו לדומיין ולקידומת הנתיב שמהם אתם מתכוונים להציג את התוכן המוגן. יכול להיות שהם יהיו שונים מהדומיין ומהנתיב שבהם קובץ ה-cookie נוצר (example.com לעומת media.example.com או /browse לעומת /videos).

• מוודאים שיש רק קובץ Cookie אחד עם שם נתון לאותו Domain וPath.

• חשוב לוודא שלא מונפקים קובצי Cookie סותרים, כי זה עלול למנוע גישה לתוכן בסשנים אחרים של הדפדפן (חלונות או כרטיסיות).

• מגדירים את הדגלים Secure ו-HttpOnly במקרים הרלוונטיים. ‫Secure מבטיח שקובץ ה-Cookie יישלח רק דרך חיבורי HTTPS. ‫HttpOnly מונע את הזמינות של קובץ ה-Cookie ל-JavaScript.

• מאפייני קובצי ה-Cookie‏ Expires ו-Max-Age הם אופציונליים. אם לא מציינים אותם, קובץ ה-Cookie קיים כל עוד סשן הדפדפן (כרטיסייה, חלון) קיים.

  הערה: מאפיין Expires שמוזכר כאן הוא המאפיין שמופיע (אם הוא קיים) מחוץ לערך של קובץ ה-Cookie. חשוב לא להתבלבל בין המאפיין הזה לבין הפרמטר Expires שכלול בערך של קובץ ה-Cookie, שהוא פרמטר חובה. הפרמטר Expires שמופיע בערך של קובץ ה-cookie מציין את מגבלת הזמן שבמהלכה Cloud CDN מאפשר למשתמש לגשת לתוכן מוגן. מגבלת הזמן הזו לא תלויה במשך החיים של קובץ ה-Cookie.

• במקרה של מילוי מטמון או אי מציאה במטמון, קובץ ה-Cookie החתום מועבר למקור שמוגדר בשירות הקצה העורפי. חשוב לוודא שאתם מאמתים את הערך של קובץ ה-Cookie החתום בכל בקשה לפני הצגת התוכן.