תהליך חתימה V2

חשוב: הדף הזה עוסק בחומרים מדור קודם שקשורים לתהליך החתימה V2. עדיף במקום זאת לעבוד עם תהליך החתימה V4.

בדף הזה יש סקירה כללית על כתובות URL חתומות כשעובדים עם תהליך החתימה V2, שהוא מנגנון לאימות מחרוזות שאילתה בקטגוריות ובאובייקטים. כתובות URL חתומות מאפשרות לתת גישת קריאה או כתיבה לזמן מוגבל לכל מי שיש להם את כתובת ה-URL, בין שיש להם או שאין להם חשבון משתמש.

חשוב: בכתובות URL חתומות אפשר להשתמש כדי לגשת למשאבים ב-Cloud Storage רק באמצעות נקודות קצה ל-API בפורמט XML.

הרכיבים במחרוזת שדורשים חתימה

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

StringToSign = HTTP_Verb + "\n" +
               Content_MD5 + "\n" +
               Content_Type + "\n" +
               Expires + "\n" +
               Canonicalized_Extension_Headers +
               Canonicalized_Resource

הרכיבים שמהם מורכב המבנה הזה מפורטים בטבלה הבאה:

רכיב המחרוזת	דוגמה	תיאור
HTTP_Verb	GET	חובה. פועל HTTP שיש להשתמש בו עם כתובת ה-URL החתומה. הערה:פועל ה-HTTP POST לא נתמך במחרוזות של כתובות URL חתומות, חוץ מאשר כפי שצוין למעלה. אפשר להשתמש ב-POST כדי להגדיר מסמכי מדיניות חתומים, שקובעים את המאפיינים של האובייקטים שאפשר להעלות לקטגוריה. מידע נוסף זמין במאמרי העזרה בנושא אובייקט POST.
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	אופציונלי. הערך של תקציר MD5 ב-Base64. אם מציינים את הפרמטר הזה במחרוזת, הלקוח (בדרך כלל דפדפן) צריך לספק בבקשה שלו את כותרת ה-HTTP הזו עם אותו הערך.
Content_Type	text/plain	לפי הצורך. אם אתם מציינים content-type, הלקוח (הדפדפן) צריך להוסיף את כותרת ה-HTTP הזו, עם אותו הערך.
Expires	1388534400	חובה. זוהי חותמת הזמן (המיוצגת כמספר השניות מאז ראשית זמן יוניקס ב-00:00:00 UTC ב-1 בינואר 1970) שמציינת מתי תוקף החתימה פג. השרת דוחה את כל הבקשות שהתקבלו אחרי חותמת הזמן הזו וגם את כל הבקשות שהתקבלו אחרי רוטציה של המפתח ששימש ליצירת כתובת ה-URL החתומה. הערך של Expires צריך להיות מוגדר כך שיתאים למשך שבוע לכל היותר (604,800 שניות), לצורך אבטחה ותאימות לתהליך החתימה של V4.
Canonicalized_Extension_Headers	x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n	לפי הצורך. השרת בודק אם הלקוח מציין ערכים תואמים בבקשות שמשתמשות בכתובת ה-URL החתומה. למידע נוסף על יצירת כותרות קנוניות לחתימה ראו כותרות תוספים קנוניות.
Canonicalized_Resource	/bucket/objectname	חובה. המשאב שכתובת ה-URL מפנה אליו. לפרטים נוספים ראו משאבים קנוניים.

הערה: הפרמטרים של מחרוזות השאילתה, כמו response-content-disposition ו-response-content-type, לא מאומתים על ידי החתימה. כדי לאלץ Content-Disposition או Content-Type בתגובה, , צריך להגדיר את הפרמטרים האלה במטא-נתונים של האובייקט.

חתימת מחרוזות באמצעות שירות App Identity של App Engine.

כשיוצרים כתובת URL חתומה באמצעות תוכנית, אפשר לחתום את המחרוזת מתוך התוכנית או מהאפליקציה App Engine באמצעות שירות הזהות של App Engine, שמשתמש בפרטי הכניסה של חשבון השירות של App Engine. לדוגמה, באמצעות ה-API ‏App Identity ל-Python תוכלו:

• לחתום את הבייטים מהמחרוזת המורכבת באמצעות google.appengine.api.app_identity.sign_blob(), ולספק את פרמטר ה-Signature שנדרש להרכבת כתובת ה-URL החתומה.

• להשתמש בפונקציה google.appengine.api.app_identity.get_service_account_name() כדי לאחזר שם של חשבון שירות, שהוא פרמטר ה-GoogleAccessId שנדרש כדי להרכיב את כתובת ה-URL החתומה.

לתמיכה בשפות אחרות, עיינו במאמרים סקירה על ה-API ‏App Identity ל-Java, ‏סקירה על ה-API ‏App Identity ל-PHP ופונקציות GO של App Identity.

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

כותרות קנוניות של תוספים

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

1. משתמשים בכל שמות הכותרות המותאמים אישית באותיות קטנות.

2. מסדרים את כל הכותרות המותאמות אישית לפי שם הכותרת בסדר אלפביתי לפי ערך מיקום התו.

3. אם הכותרות x-goog-encryption-key ו-x-goog-encryption-key-sha256 נמצאות, מסירים אותן. הכותרות האלה מכילות מידע רגיש שאסור לכלול ב'מחרוזת לחתימה'; אבל הן בכל זאת נחוצות בבקשות שמשתמשות בכתובת ה-URL החתומה שנוצרה.

4. מבטלים שמות כפולים של כותרות על ידי יצירת שם כותרת אחד עם רשימת ערכים שמופרדים בפסיקים. חשוב לוודא שאין רווח בין הערכים ולהקפיד שהסדר של הרשימה שמופרדת בפסיקים תואם לסדר שבו הכותרות מופיעות בבקשה. מידע נוסף זמין ב-RFC 7230, סעיף 3.2.

5. מחליפים רצפים של רווח לבן ומעברי שורות (CRLF או LF) ברווח אחד. מידע נוסף על רצפים של רווח לבן זמין ב-RFC 7230, סעיף 3.2.4..

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

7. מוסיפים באמצעות פעולת append שורה חדשה "‎"\n"‏ (U+000A) לכל כותרת מותאמת אישית.

8. משרשרים (במחרוזת) את כל הכותרות המותאמות אישית.

‫

חשוב: צריך להשתמש גם בשם הכותרת וגם בערך הכותרת כשמרכיבים את החלק 'כותרות תוספים קנוניות' של מחרוזת השאילתה. חשוב להסיר רווחים מסביב לנקודתיים שמפרידות בין השם והערך של הכותרת. לדוגמה, שימוש בכותרת המותאמת אישית x-goog-acl: private מבלי להסיר את הרווח שאחרי הנקודתיים, מחזיר שגיאת 403 Forbidden מכיוון שחתימת הבקשה המחושבת לא תואמת לחתימה ש-Cloud Storage מחשב.

משאבים קנוניים

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

• המשאב הקנוני הוא כל מה שמופיע אחרי שם המארח. לדוגמה, אם כתובת ה-URL של Cloud Storage היא https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, המשאב הקנוני הוא /example-bucket/cat-pics/tabby.jpeg.

• אם הבקשה היא בהיקף של משאב משנה, למשל ?cors, צריך להוסיף את משאב המשנה הזה, כולל סימן השאלה, בסוף המחרוזת.

• צריך להקפיד להעתיק את נתיב בקשת ה-HTTP באופן מילולי, כלומר, לכלול את כל הקידוד של כתובות ה-URL (סימני האחוזים) במחרוזת שאתם יוצרים. חשוב גם לכלול רק פרמטרים של מחרוזת שאילתה שמציינים משאבי משנה (כמו cors). אסור לכלול פרמטרים של מחרוזת שאילתה כמו ?prefix, ?max-keys, ?marker ו-?delimiter.